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CHAPTER  1 


INTRODUCTION 


The  Ada  implementation  described  above  was  tested  according  to  the  Ada 
Validation  Procedures  [Pro901  against  the  Ada  Standard  [Ada83]  using  the 
current  Ada  Compiler  Validation  Capability  (ACVC).  This  Validation  Summary 
Report  (VSR)  gives  an  account  of  the  testing  of  this  Ada  implementation* 

For  any  technical  terms  used  in  this  report,  the  reader  is  referred  to 
[Pro90].  A  detailed  description  of  the  ACVC  may  be  found  in  the  current 
ACVC  User's  Guide  (UG891. 


1.1  USE  OF  THIS  VALIDATION  SUMMARY  REPORT 

Consistent  with  the  national  lavs  of  the  originating  country,  the  Ada 
Certification  Body  may  make  full  and  free  public  disclosure  of  this  report. 
In  the  United  States,  this  is  provided  in  accordance  with  the  "Freedom  of 
Information  Act"  (5  U.S.C.  #552).  The  results  of  this  validation  apply 
only  to  the  computers,  operating  systems,  and  compiler  versions  identified 
in  this  report. 

The  organizations  represented  on  the  signature  page  of  this  report  do  not 
represent  or  warrant  that  all  statements  set  forth  in  this  report  are 
accurate  and  complete,  or  that  the  subject  implementation  has  no 
nonconformities  to  the  Ada  Standard  other  than  those  presented.  Copies  of 
this  report  are  available  to  the  public  from  the  AVF  which  performed  this 
validation  or  from: 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield  VA  22161 


Questions  regarding  this  report  or  the  validation  test  results  should  be 
directed  to  the  AVF  which  performed  this  validation  or  to: 

Ada  Validation  Organization 
Institute  for  Defense  Analyses 
1801  North  Beauregard  Street 
Alexandria  VA  22311 
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1 . 2  REFERENCES 

[Ada83]  Reference  Manual  for  the  Ada  Programming  Language, 

ANSI/MIL-STD-1815A,  FeUruary  1983  and  ISO  865^-1987. 

[Pro90J  Ada  Compiler  Validation  Procedures,  Version  2.1,  Ada  Joint  Program 
off  ice,  August  19$(I). 

[UG89]  Ada  Compiler  Validation  Capability  User's  Guide,  21  June  1989. 


1.3  ACVC  TEST  CLASSES 

Compliance  of  Ada  implementations  is  tested  by  means  of  the  ACVC.  The  ACVC 
contains  a  collection  of  test  programs  structured  into  six  test  classes: 

A,  B,  C,  D,  E,  and  L.  The  first  letter  of  a  test  name  identifies  the  class 
to  which  it  belongs.  Class  A,  C,  D,  and  E  tests  are  executable.  Class  B 
and  class  L  tests  are  expected  to  produce  errors  at  compile  time  and  link 
time,  respectively. 

The  executable  tests  are  written  in  a  self-checking  manner  and  produce  a 
PASSED,  FAILED,  or  NOT  APPLICABLE  message  indicating  the  result  when  they 
are  executed.  Three  Ada  library  units,  the  packages  REPORT  and  SPPRT13, 
and  the  procedure  CHECK  FILE  are  used  for  this  purpose.  The  package  REPORT 
also  provides  a  set  of  Identity  functions  used  to  defeat  some  compiler 
optimizations  allowed  by  the  Ada  Standard  that  would  circumvent  a  test 
objective.  The  package  SPPRT13  is  used  by  many  tests  for  Chapter  13  of  the 
Ada  Standard.  The  procedure  CHECK_FILE  is  used  to  check  the  contents  of 
text  files  written  by  some  of  the  Class  C  tests  for  Chapter  14  of  the  Ada 
Standard.  The  operation  of  REPORT  and  CHECK_FILE  is  checked  by  a  set  of 
executable  tests.  If  these  units  are  not  operating  correctly,  validation 
testing  is  discontinued. 

Class  B  tests  check  that  a  compiler  detects  illegal  language  usage.  Class 
B  tests  are  not  executable.  Each  test  in  this  class  is  compiled  and  the 
resulting  compilation  listing  is  examined  to  verify  that  all  violations  of 
the  Ada  Standard  are  detected.  Some  of  the  class  B  tests  contain  legal  Ada 
code  which  must  not  be  flagged  illegal  by  the  compiler.  This  behavior  is 
also  verified. 

Class  L  tests  check  that  an  Ada  implementation  correctly  detects  violation 
of  the  Ada  Standard  involving  multiple,  separately  compiled  units.  Errors 
are  expected  at  link  time,  and  execution  is  attempted. 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be  replaced  by 
implementation-specific  values  —  for  example,  the  largest  integer.  A  list 
of  the  values  used  for  this  implementation  is  provided  in  Appendix  A.  In 
addition  to  these  anticipated  test  modifications,  additional  changes  may  be 
required  to  remove  unforeseen  conflicts  between  the  tests  and 
implementation-dependent  characteristics.  The  modifications  required  for 
this  implementation  are  described  in  section  2.3. 
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For  each  Ada  implementation,  a  customized  test  suite  is  produced  by  the 
AVF.  This  customization  consists  of  making  the  modifications  described  in 
the  preceding  paragraph,  removing  withdrawn  tests  (see  section  2.1)  and, 
possibly  some  inapplicable  tests  (see  Section  2.2  and  [UG89]). 

In  order  to  pass  an  ACVC  an  Adi  implementation  must  process  each  test  of 
the  customized  test  suite  according  to  the  Ada  Standard. 


1.4  DEFINITION  OF  TERMS 


Ada  Compiler 


Ada  Compiler 
Validation 
Capability 
(ACVC) 

Ada 

Implementation 

Ada  Joint 
Program 
Office  (AJPO) 

Ada 

Validation 
Facility  (AVF) 

Ada 

Validation 

Organization 

(AVO) 

Compliance  of 
an  Ada 

Implementation 

Computer 

System 


The  software  and  any  needed  hardware  that  have  to  be  added 
to  a  given  host  and  target  computer  system  to  allow 
transformation  of  Ada  programs  into  executable  form  and 
execution  thereof. 

The  means  for  testing  compliance  of  Ada  implementations, 
consisting  of  the  test  suite,  the  support  programs,  the  ACVC 
user's  guide  and  the  template  for  the  validation  summary 
report . 

An  Ada  compiler  with  its  host  computer  system  and  its 
target  computer  system. 

The  part  of  the  certification  body  which  provides  policy  and 
guidance  for  the  Ada  certification  system. 


The  part  of  the  certification  body  which  carries  out  the 
procedures  required  to  establish  the  compliance  of  an  Ada 
implementation. 

The  part  of  the  certification  body  that  provides  technical 
guidance  for  operations  of  the  Ada  certification  system. 


The  ability  of  the  implementation  to  pass  an  ACVC  version. 


A  functional  unit,  consisting  of  one  or  more  computers  and 
associated  software,  that  uses  common  storage  for  all  or 
part  of  a  program  and  also  for  all  or  part  of  the  data 
necessary  for  the  execution  of  the  program;  executes 
user-written  or  user-designated  programs;  performs 
user-designated  data  manipulation,  including  arithmetic 
operations  and  logic  operations;  and  that  can  execute 
programs  that  modify  themselves  during  execution.  A 
computer  system  may  be  a  stand-alone  unit  or  may  consist  of 
several  inter-connected  units. 
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IMPLEMENTATION  DEPENDENCIES 


2.1  VIIHDRAWN  TESTS 

The  following  tests  have  been  withdrawn  by  the  AVO.  The  rationale  for 
withdrawing  each  test  is  available  from  either  the  AVO  or  the  AVF.  The 
publication  date  for  this  list  of  withdrawn  tests  is  11  November  1990. 


E28005C 

B28006C 

C34006D 

C35702A 

B41308B 

C43004A 

C45114A 

C45346A 

C45612B 

C45651A 

C46022A 

B49008A 

A74006A 

C74308A 

B83022B 

B83022H 

B83025B 

B83025D 

B83026B 

C83026A 

C83041A 

B85001L 

C97116A 

C98003B 

BA2011A 

CB7001A 

CFi7001B 

CB7004A 

CC1223A 

BC1226A 

CC1226B 

BC3009B 

BD1B02B 

BD1B06A 

AD1B08A 

BD2A02A 

CD2A21E 

CD2A23E 

CD2Aj2A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

BD3006A 

BD4008A 

CD4022A 

CD4022D 

CD4024B 

CD4024C 

CD4024D 

CD4031A 

CD4051D 

CD5111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

AD7201A 

AD7201E 

CD7204B 

BD8002A 

BD8004C 

CD9005A 

CD9005B 

CDA201E 

CE2107I 

CE2117A 

CE2117B 

CE2119B 

CE2205B 

CE2405A 

CE3111C 

CE3116A 

CE3118A 

CE3411B 

CE3412B 

CE3607B 

CE3607C 

CE3607D 

CE3812A 

CE3814A 

CE3902B 

2.2  INAPPIICABLE  TESTS 

A  test  is  inapplicable  if  it  contains  test  objectives  which  are  irrelevant 
for  a  given  Ada  implementation.  Reasons  for  a  test's  inapplicability  may 
be  supported  by  documents  issued  by  ISO  and  the  AJPO  known  as  Ada 
Commentaries  and  commonly  referenced  in  the  format  Al-ddddd.  For  this 
implementation,  the  following  tests  were  determined  to  be  inapplicable  for 
the  reasons  indicated;  references  to  Ada  Commentaries  are  included  as 
appropriate. 
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The  following  201  tests  have  floating-point  type  declarations  requiring 
more  digits  than  SYSTEM . MAX  DIGITS : 


C24113L..Y  (14  tests) 
C35706L..Y  (14  tests) 
C35708L..Y  (14  tests) 
C45241L..Y  (14  tests) 
C4542U...Y  (14  tests) 
C45524L..Z  (15  tests) 
C45641L..y  (14  tests) 


C35705L..Y  (14  tests) 
C35707L..Y  (14  tests) 
C35802L..Z  (15  tests) 
C45321L..Y  (14  tests) 
C45521L..Z  (15  tests) 
C45621L..Z  (15  tests) 
C46012L. .Z  (15  tests) 


The  following  21  tests  check  for  the  predefined  type  LONG  INTEGER: 


C35404C 

C45231C 

C45304C 

C45411C 

C45412C 

C45502C 

C45503C 

C45504C 

C45504F 

C45611C 

C45612C 

C45613C 

C45614C 

C45631C 

C45632C 

B52004D 

C55B07A 

B55B09C 

B86001W 

C86006C 

CD7101F 

A35801E  checks  that  FLOAT 'FIRST. .FLOAT 'LAST  may  be  used  as  a  range 
constraint  in  a  floating-point  type  declaration;  for  this 
implementation,  that  range  exceeds  the  range  of  safe  numbers  of  the 
largest  predefined  floating-point  type  and  must  be  rejected.  (See 
section  2.3. ) 


C35702B,  C35713C,  B86001U,  and  C86006G  check  for  the  predefined  type 
LONG  FLOAT. 


C35713D  and  B86001Z  check  for  a  predefined  floating-point  type  with  a 
name  other  than  FLOAT,  L0NG_FL0AT,  or  SH0RT_FL0AT. 

C45531M..P  and  C45532M..P  (8  tests)  check  fixed-point  operations  for 
types  that  require  a  SYSTEM. MAX_MANTISSA  of  47  or  greater;  for  this 
implementation,  MAX_MANTISSA  is  less  than  47. 

C45536A,  C46013B,  C46031B,  C46033B,  and  C46034B  contain  'SMALL 
representation  clauses  which  are  not  powers  of  two  or  ten. 

C45624A  checks  that  the  proper  exception  is  raised  if  MACHINEOVERFLOWS 
is  FALSE  for  floating  point  types  with  digits  5.  For  this 
implementation,  MACHINE_0VERFL0WS  is  TRUE. 

C45624B  checks  that  the  proper  exception  is  raised  if  MACHINE_0VERFL0WS 
is  FALSE  for  floating  point  types  with  digits  6.  For  this 
implementation,  MACHINE_OVERFLOWS  is  TRUE. 

C86001F  recompiles  package  SYSTEM,  making  package  TEXTIO,  and  hence 
package  REPORT,  obsolete.  For  this  implementation,  the  package  TEXT_I0 
is  dependent  upon  package  SYSTEM. 

B86001Y  checks  for  a  predefined  fixed-poini  type  other  than  DURATION. 
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C96005B  checks  for  values  of  type  DURATION'BASE  that  are  outside  the 
range  of  DURATION.  There  are  no  such  values  for  this  implementation. 

CD1009C  uses  a  representation  clause  specifying  a  non-default  size  for  a 
floating-point  type. 

CD2A53A  checks  operations  of  a  fixed-point  type  for  which  a  length 
clause  specifies  a  power-of-ten  TYPE' SHALL;  this  implementation  does  not 
support  decimal  'SMALLs.  (See  section  2.3.) 

CD2A84A,  CD2A84E,  CD2A84I..J  (2  tests),  and  CD2A840  use  representation 
clauses  specifying  non-default  sizes  for  access  types. 

BD8001A,  BD8003A,  BD8004A..B  (2  tests),  and  AD8011A  use  machine  code 
insertions. 

EE2401D  uses  instantiations  of  package  DIRECT_IO  with  uncons tr.  Ip  ;d 
array  types.  This  implementation  raises  USE_ERROR  on  the  attempt  to 
create  a  file  of  such  type. 

The  tests  listed  in  the  following  table  check  that  USE_ERR0R  is  raised 
if  the  given  file  operations  are  not  supported  for  the  given  combination 
of  mode  and  access  method;  this  implementation  supports  these 
operations . 


Test  File  Operation  Mode  File  Access  Method 


CE2102D 

CREATE 

IN  FILE 

SEQUENTIAL  10 

CE2102E 

CREATE 

OUT  FILE 

SEQUENTIAL"I0 

CE2102F 

CREATE 

INOUT  FILE 

DIRECT  10 

CE2102I 

CREATE 

IN  FILE 

DIRECT’IO 

CE2102J 

CREATE 

OUT  FILE 

DIRECT~I0 

CE2102N 

OPEN 

IN  FILE 

SEQUENTIAL  10 

CE21020 

RESET 

IN  FILE 

SEQUENTIAL  10 

CE2102P 

OPEN 

OUT  FILE 

SEQUENTIAL’IO 

CE21020 

RESET 

OUT  FILE 

SEQUENTIAL  10 

CE2102R 

OPEN 

inoOt  file 

DIRECT  10  " 

CE2102S 

RESET 

INOUT  FILE 

direct'io 

CE2102T 

OPEN 

IN  FILE 

DIRECT  10 

CE2102U 

RESET 

IN  FILE 

DIRECT~I0 

CE2102V 

OPEN 

OUT  FILE 

DIRECT  10 

CE2102V 

RESET 

out“file 

DIRECT  10 

CE3102E 

CREATE 

IN  Pile 

TEXT  10 

CE3102F 

RESET 

Any  Mode 

TEXT  10 

CE3102G 

DELETE 

text~io 

CE3102I 

CREATE 

OUT  file 

TEXT  iO 

CE3102J 

OPEN 

in  File 

TEXT  10 

CE3102K 

OPEN 

OUT  file 

TEXT  10 

IMPLEMENTATION  DEPENDENCIES 


The  following  16  tests  check  operations  on  sequential,  direct,  and  text 
files  when  multiple  internal  files  are  associated  with  the  same  external 
file  and  one  or  more  are  open  for  writing;  USE_ERROR  is  raised  when  this 
association  is  attempted. 


CE2107B..E  CE2107G..H  CE2107L  CD2110B  CE2110D 

CE2111D  CE2111H  CE3111B  CE3111D. .E  CE3114B 

CE3115A 

CE2203A  checks  that  WRITE  raises  USE_ERROR  if  the  capacity  of  the 
external  file  is  exceeded  for  SEQUENTIAL_IO .  This  implementation  does 
not  restrict  file  capacity. 

CE2403A  checks  that  WRITE  raises  USE_ERROR  if  the  capacity  of  the 
external  file  is  exceeded  for  DIRECT_I0.  This  implementation  does  not 
restrict  file  capacity. 

CE3111B,  CE3111D..E  (2  tests),  CE3114B,  and  CE3115A  attempt  to  associate 
multiple  internal  files  with  the  same  external  file  when  one  or  more 
files  is  writing  for  text  files.  The  proper  exception  is  raised  when 
multiple  access  is  attempted. 

CE330AA  checks  that  USE_ERROR  is  raised  if  a  call  to  SET  LINE  LENGTH  or 
SET_PAGE  LENGTH  specifies  a  value  that  is  inappropriate  Tor  tHe  external 
file.  TRis  implementation  does  not  have  inappropriate  values  for  either 
line  length  or  page  length. 

CE3305A  checks  the  SET_LINE_LENGTH  procedure,  including  the  particular 
call  SET  LINE_LENGTH  (UNBOUNDED);  this  implementation  does  not  support 
unbounded  lines. 

CE3413B  checks  that  PAGE  raises  LAYOUT_ERROR  when  the  value  of  the  page 
number  exceeds  COUNT' LAST.  For  this  implementation,  the  value  of 
COUNT'LAST  is  greater  than  150000  making  the  checking  of  this  objective 
impractical. 


2.3  TEST  MODIFICATIONS 

Modifications  (see  section  1.3)  were  required  for  22  tests. 

The  following  tests  were  split  into  two  or  more  tests  because  this 
implementation  did  not  report  the  violations  of  the  Ada  Standard  in  the  way 
expected  by  the  original  tests. 


B23004A 

B24007A 

B24009A 

B28003A 

B28003C 

B32202A 

B32202B 

B32202C 

B33001A 

B37004A 

B45102A 

B61012A 

B62001B 

BC3009C 

B91004A 

B95069A 

B95069B 

BAllOlBl 

BC2001D 
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A3S801E  vas  graded  inapplicable  by  Evaluation  Modification  as  directed 
by  the  AVO.  The  compiler  rejects  the  use  of  the  range 
FLOAT' FIRST. .FLOAT' LAST  as  the  range  constraint  of  a  floating-point 
type  declaration  because  the  bounds  lie  outside  of  the  range  of  safe 
numbers  (cf.  LRM  3.5.7:12).  b.  CD2A53A  vas  graded  inapplicable  by 
Evaluation  Modification  as  directed  by  the  AVO.  The  test  contains  a 
specification  of  a  pover-of-10  value  as  'SMALL  for  a  fixed-point  type. 
The  AVO  ruled  that,  under  ACVC  1.11,  support  of  decimal  'SMALLs  may  be 
omitted. 

AD9001B  was  graded  passed  by  Test  Modification  as  directed  by  the  AVO. 
This  test  checks  that  no  bodies  are  required  for  interfaced 
subprograms;  among  the  procedures  that  it  uses  is  one  with  a  parameter 
of  mode  OUT  (line  36).  This  implementation  does  not  support  pragma 
INTERFACE  for  procedures  with  parameters  of  mode  OUT.  The  test  was 
modified  by  commenting  out  line  36;  the  modified  test  passed,  b. 
EA300^n  was  graded  passed  by  Evaluation  and  Processing  Modification  as 
directed  by  the  AVO.  The  test  requires  that  either  pragma  INLINE  is 
obeyed  for  a  function  call  in  each  of  three  contexts  and  that  thus 
three  library  units  are  made  obsolete  by  the  re-compilation  of  the 
inlined  function's  body,  or  else  the  pragma  is  ignored  completely. 

This  implementation  obeys  the  pragma  except  when  the  call  is  within 
the  package  specification.  When  the  test's  files  are  processed  in  the 
given  order,  only  two  units  are  made  obsolete;  thus,  the  expected 
error  at  line  27  of  file  EA3004D6M  is  not  valid  and  is  not  flagged. 

To  confirm  that  indeed  the  pragma  is  not  obeyed  in  this  one  case,  the 
test  vas  also  processed  with  the  files  re-ordered  so  that  the 
re-compilation  follows  only  the  package  declaration  (and  thus  the 
other  library  units  will  not  be  made  obsolete,  as  they  are  compiled 
later);  a  "NOT  APPLICABLE"  result  was  produced,  as  expected.  The 
revised  order  of  files  vas  0-1-4-5-2-3-6. 

BA2001E  was  graded  passed  by  Evaluation  Modification  as  directed  by 
the  AVO.  The  test  expects  that  duplicate  names  of  subunits  with  a 
common  ancestor  will  be  detected  as  compilation  errors;  this 
implementation  detects  the  errors  at  link  time,  and  the  AVO  ruled  that 
this  behavior  is  acceptable. 
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CHAPTER  3 


PROCESSING  INFORMATION 


3.1  TESTING  ENVIRONMENT 

The  Ada  implementation  tested  in  this  validation  effort  is  described 
adequately  by  the  information  given  in  the  initial  pages  of  this  report. 

For  a  point  of  contact  for  technical  information  about  this  Ada 
implementation  system,  see: 

Fred  Rozakis 

One  Industrial  Avenue 

Lowell  MA  01851 

For  a  point  of  contact  for  sales  information  about  this  Ada  implementation 
system,  see; 


Fred  Rozakis 

One  Industrial  Avenue 

Lowell  MA  01851 


Testing  of  this  Ada  implementation  was  conducted  at  the  customer's  site  by 
a  validation  team  frqm  the  AVF. 


3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  Implementation  passes  a  given  ACVC  version  if  it  processes  each  test 
of  the  customized  test  suite  in  accordance  with  the  Ada  Programming 
Language  Standard,  whether  the  test  is  applicable  or  inapplicable; 
otherwise,  the  Ada  Implementation  fails  the  ACVC  |Pro90J. 

For  all  processed  tests  (inapplicable  and  applicable),  a  result  was 
obtained  that  conforms  to  the  Ada  Programming  Language  Standard. 
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Total  Number  of  Applicable  Tests  3786 

Total  Number  of  Vithdravn  Tests  83 

Processed  Inapplicable  Tests  100 

Non-Processed  I/O  Tests  0 

Non-Processed  Floating-Point 

Precision  Tests  201 

Total  Number  of  Inapplicable  Tests  301 


Total  Number  of  Tests  for  ACVC  1.11  4170 


All  I/O  tests  of  the  test  suite  were  processed  because  this  implementation 
supports  a  file  system.  The  above  number  of  floating-point  tests  were  not 
processed  because  they  used  floating-point  precision  exceeding  that 
supported  by  the  implementation.  When  this  compiler  was  tested,  the  tests 
listed  in  section  2.1  had  been  withdrawn  because  of  test  errors. 


3 . 3  TEST  EXECUTION 

Version  1.11  of  the  ACVC  comprises  4170  tests.  When  this  compiler  was 
tested,  the  tests  listed  in  section  2.1  had  been  withdrawn  because  of  test 
errors.  The  AVF  determined  that  303  tests  were  inapplicable  to  this 
implementation.  All  inapplicable  tests  were  processed  during  validation 
testing  except  for  201  executable  tests  that  use  floating-point  precision 
exceeding  that  supported  by  the  implementation.  In  addition,  the  modified 
tests  mentioned  in  section  2.3  were  also  processed. 

MS-DOS  diskettes  containing  the  customized  test  suite  (see  section  1.3) 
were  taken  on-site  by  the  validation  team  for  processing.  The  contents  of 
the  diskettes  were  transferred  to  a  PC.  A  batch  file  was  used  to  upload 
the  files  to  the  host  computer.  The  uploading  was  done  using  PCVS,  a 
PC-to-VS  file  transfer  program  which  uses  a  V'ang  928  communications  link. 


After  the  test  files  were  loaded  onto  the  host  computer,  the  furl  set  of 
tests  was  processed  by  the  Ada  implementation.  The  test  load  was  shared 
between  two  identical  Vang  VS  8480  configurations. 


Testing  was  performed  using  command  scripts  provided  by  the  customer  and 
reviewed  by  the  validation  team.  See  Appendix  B  for  a  complete  listing  of 
the  processing  options  for  this  implementation.  It  also  indicates  the 
default  options.  The  options  invoked  explicitly  for  validation  testing 
during  this  test  were: 


Effect 


Do  not  generate  symbolic  debugger  info 


Option/Switch 

Compiler: 

Debug-No 
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Level-Object 

Generics-Yes 

Errors«999 

Hemory-256 

Annotate-No 

Checks -All 

Inline-Yes 

Reduct -No 

Express-No 

Peephole-YfeS 

Source=Yes/No 


Dmap-No 

Pmap-No 

Varning-No 

Oetail-No 

Linelen-79 

Banner-Yes 

Stack-1024 

Global-1024 

Unnested-16 

Binder  5 

Debug-No 

Level-Link 

Trace-No 

Data«No 

Modules-No 

Uncalled-Yes 

Varning-Yes 

Stack-64 

Task-16 

Heap-256 

Moreheap-4 

Cancel-No 

loerrors-No 

Linker: 

Map-Yes 

Symbolic-Yes 

Linkage-Yes 

Staticsl«No 

Sharedsl-No 

Entnames-No 

Alias -No 

Reorder-No 

Resolve-Yes 


Generate  object  code 

Inline  code  for  generics 

Permit  999  compilation  errors 

Reserve  256  kilobytes  in  memory  for  program 

library  data 

Do  not  save  comments  in  program  library 
Enable  full  run-time  checking 
Inline  code 

Turn  off  high-level  optimization 
Turn  off  lov-level  optimization 
Turn  on  peephole  optimization 

Include  source  text  in  listing  for  E  tests,  .TST 
tests,  and  for  tests  which  yield  compilation  errors. 
Do  not  include  source  text  for  the  remainder. 

Do  not  include  data  map  in  listing 
Do  not  include  program  map  in  listing 
Do  not  include  warning  messages  in  listing 
Do  not  include  extra  info  detail  in  listing 
Use  79  for  width  of  listing  file 
Include  banners  in  listing 
Allocate  1024  for  stack  objects 
Allocate  1024  for  global  objects 
Allocate  16  for  unnested  objects 


Do  not  generate  symbolic  debugger  info 
Link  after  binding 

Do  not  generate  trace  info  for  unhandled 
exceptions 

Do  not  include  program  data  in  listing 

Do  not  link  other  modules  with  the  Ada 

program  module 

Remove  uncalled  subprograms 

Include  warnings  in  bind  listing 

Reserve  64  kilobytes  for  program  stack 

Reserve  16  kilobytes  for  each  task  stack 

Reserve  256  kilobytes  for  initial  program  heap 

Add  4  kilobytes  to  heap  when  it  is  full 

Do  not  intercept  program  cancels 

Do  not  display  10  errors  on  workstation 


Create  a  link  map 
Retain  symbolic  data 
Retain  linkage  data 

Do  not  create  a  static  subroutine  library 
Do  not  create  a  shared  subroutine  library 
Do  not  select  subroutine  library  entry  names 
Do  not  assign  aliases  to  SSL  symbols 
Do  not  reorder  output  program  section 
Resolve  undefined  symbols  interactively 


3-3 


PROCESSING  INFORMATION 


Djpsect-No 

Inprogrs«No 

Obj£orm«l 

Varnings-Yes 

Datesel-No 


Resolve  duplicate  section  names  interactively 
Do  not  display  in-program  screen 
Use  object  file  format  '1' 

Print  small  link  map  of  errors  or  warnings 
Do  not  select  duplicate  sections  by  date 


Test  output,  compiler  and  linker  listings,  and  job  logs  were  captured  on 
magnetic  tape  and  archived  at  the  AVF.  The  listings  examined  on-site  by 
the  validation  team  were  also  archived. 
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MACRO  PARAMETERS 


This  appendix  contains  the  macro  parameters  used  for  customizing  the  ACVC. 
The  meaning  and  purpose  of  these  parameters  are  explained  in  [UG89].  The 
parameter  values  are  presented  in  two  tables.  The  first  table  lists  the 
values  that  are  defined  in  terms  of  the  maximum  input-line  length,  which  is 
the  value  for  $MAX_IN_LEN — also  listed  here.  These  values  are  expressed 
here  as  Ada  string'aggregates,  where  "V"  represents  the  maximum  input-line 
length. 


Macro  Parameter 


Macro  Value 


$BIG_ID1 

(1..V-1  =>  'A',  V  ->  '1') 

SBIG_ID2 

(1..V-1  «>  'A',  V  ->  '2') 

$BIG_ID3 

(1. .V/2  ->  'A' )  &  '3'  & 
(1..V-1-V/2  ->  'A') 

$BIG_ID4 

(1. .V/2  ->  'A')  &  '4'  & 
(1..V-1-V/2  .>  'A') 

$BIG_INT_LIT 

(1. .V-3  ->  '0' )  &  "298" 

$BIG_REAL_LIT 

(1..V-5  ->  '0')  &  "690.0" 

$BIG_STRING1 

6  (1..V/2  .>  'A')  & 

$BIG_STRING2 

(,  (1..V-1-V/2  ->  'A')  &  ' 

$BLANKS 

(1..V-20 

$MAX_LEN_INT_BASED_ 

LITERAL 

"2:"  &  (1..V-5  =>  '0')  &  "11: 

$MAX_LEN_REAL_BASED 

LITERAL 

"16:"  &  (1..V-7  ->  '0')  &  "F. 

$MAX  STRING  LITERAL 

&  (1..V-2  ->  'A')  & 
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The  following  table  lists  all  of  the  other  macro  parameters  and  their 
respective  values. 

Macro  Parameter  Macro  Value 


$MAX_IN_LEN 

$ACC_SIZE 

$ALIGNMENT 

$COUNT_LAST 

$DEFAULT_MEM_SIZE 

$DEFAULT_STOR_UNIT 

$DEFAULT_SYS_NAME 

SbELTADOC 

$ENTRY_ADDRESS 

$ENTRY_ADDRESS1 

$ENTRY_ADDRESS2 

$FIELD_LAST 

$FILE__TERMINATOR 

$FIXED_NAME 

$FLOAT_NAME 

SFORM_STRING 

SF0RM_STRING2 

SGREATER  THAN  DURATION 


255 

32 

4 

2147483647 

16777216 

8 

WANG_VS 
2#1.0#E-31 
SYSTEM. NULL_ADDRESS 
SYSTEM . NULL_ADDRESS 
SYSTEM . NULL_ADDRESS 
255 

f  9 

NO_SUCH_FIXED_TYPE 

NO_SUCH_TYPE 

ff 

"CANNOT  RESTRICT  FILE  CAPACITY 


»• 


100000.0 

SGREATER  THAN_DURATIOn  BASE  LAST 

TooooSoo.o 

SGREATER  THAN_FLOAT  BASE  LAST 

7.23700557733226E+75 

SGREATER  THAN  FLOAT_SAFE  LARGE 

16i0 .  FFFFFFFFFFFFF9#E-t.63 
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$GREATER  THAN  SHORT  FLOAT  SAFE  LARGE 

7.25701E+75 

$HIGH_PRIORITY  1 

$ILLEGAL  EXTERNAL_FILE  NAMEl 

BAD-FNAM 

$ I LLEGAL_EXTERNAL_FI LE_NAME2 

THIS-FILE-NAME-IS-TOO-LONG-FOR-MY-SYSTEM 

SINAPPROPRIATE  LINE_LENGTH 

SINAPPROPRIATE  PAGE  LENGTH 

-1 


$INCLUDE_PRAGMA1 

$INCLUDE_PRAGMA2 

$INTEGER_FIRST 

$INTEGER_LAST 

$INTEGER_LAST_PLUS_1  2147483648 

$INTERFACE_LANGUAGE  C 

$LESS_THAN_DURATION  -100000.0 

SLESS  THAN  DURATION_BASE  FIRST 

-10000000.0 


PRAGMA  INCLUDE  ( ''A28006D1 .  TST" ) 
PRAGMA  INCLUDE  ( "B28006F1 . TST" ) 
-2147483648 
214748647 


SLINE_TERMINATOR 
SLOWPRIORITY  1 

$MACHINE_CODE_STATEMENT 


NULL; 

$MACHINE_CODE_TYPE 

NO_SUCH_TYPE 

$MANTISSA_D0C 

31 

SMAXDIGITS 

15 

SMAX_INT 

2147483647 

$HAX_INT_PLUS_1 

2147483648 

SMIN  INT 

2147483647 
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$NAME 

$NAME_LIST 

$NAME_SPECIFICATIONl 

$NAME_SPECIFICATION2 

$NAME_SPECIFICATION3 

$NEG_BASED_INT 

$NEW_MEM_SIZE 

SNEW_STOR_UNIT 

$NEW_SYS_NAME 

$PAGE_TERMINATOR 

$RECORD_DEFINITION 

$RECORD_NAME 

$TASK_SIZE 

$TASK_STORAGE_SIZE 

$TICK 

$VARIABLE_ADDRESS 

$VARIABLE_ADDRESS1 

$VARIABLE_ADDRESS2 

$YOUR_PRAGMA 


SHORT_SHORT_INTEGER 

WANG_VS 

ACVC . ACVCDATA . X2 1 2  OA 
ACVC . ACVCDATA . X2 1 20B 
ACVC . ACVCDATA . X3 1 1 9 A 
16#FFFFFFFF# 

0 

0 

WANG_VS 

t  f 

NEW  INTEGER; 

NO_SUCH_MACHINE_CODE_TYPE 

32 

16384 

0.01 

V_ADDRESS 

V_ADDRESS1 

V_ADDRESS2 

PACK 
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COMPILATION  SYSTEM  OPTIONS 


The  compiler  options  of  this  Ada  implementation,  as  described  in  this 
Appendix,  are  provided  by  the  customer.  Unless  specifically  noted 
otherwise,  references  in  this  appendix  are  to  compiler  documentation  and 
not  to  this  report. 
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Option/Switch 


Effect 


Debug=No 

Level=Object 

GenericsoYes 

Errors*50 

Metnory=500 

Annota  te=No 

Checks=All 

Inline=No 

Reduct=»No 

ExpresssNo 

Peephole-Yes 

Source-No 

Dmap-No 

Pmap-No 

Warning=Yes 

Detail=Yes 

Linelen=132 

Banner-Yes 

Stack=1024 

Global=1024 

Unnested=16 


Do  not  generate  symbolic  debugger  info 

Generate  object  code 

Inline  code  for  generics 

Permit  50  compilation  errors 

Reserve  500  kilobytes  in  memory  for  program 

library  data 

Do  not  save  comments  in  program  library 
Enable  full  run-time  checking 
Do  not  Inline  code 
Turn  off  high-level  optimization 
Turn  off  low-level  optimization 
Turn  on  peephole  optimization 
Do  not  include  source  text  in  listing 
Do  not  include  data  map  in  listing 
Do  not  include  program  map  in  listing 
Include  warning  messages  in  listing 
Include  extra  info  detail  in  listing 
Use  132  for  width  of  listing  file 
Include  banners  in  listing 
Allocate  1024  for  stack  objects 
Allocate  1024  for  global  objects 
Allocate  16  for  unnested  objects 
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LINKER  OPTIONS 

The  linker  options  of  this  Ada  implementation,  as  described  in  this 
Appendix,  are  provided  by  the  customer.  Unless  specifically  noted 
otherwise,  references  in  this  appendix  are  to  linker  documentation  and  not 
to  this  report. 
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Option/Svitch 


Effect 


Binder: 

Debug=No 

Level»Link 

Trace=No 

Data=No 

Modules»No 

Uncalled=Yes 

WarningaYes 

Stack=64 

Task=16 

Heapa256 

Moreheap=4 

Cancel=No 

Ioerrors=No 

Linker: 

Map=Yes 

SymbolicaYes 

Linkage=Yes 

StaticslaNo 

SharedslaNo 

EntnamesaNo 

AliasaNo 

ReorderaNo 

ResolveaYes 

DupsectaNo 

InprogrsaNo 

Obj  formal 

WarningsaYes 

DateselaNo 


Do  not  generate  symbolic  debugger  info 
Link  after  binding 

Do  not  generate  trace  info  for  unhandled 
exceptions 

Do  not  include  program  data  in  listing 

Do  not  link  other  modules  with  the  Ada 

program  module 

Remove  uncalled  subprograms 

Include  warnings  in  bind  listing 

Reserve  64  kilr'^ytes  for  program  stack 

Reserve  16  kilobytes  for  each  task  stack 

Reserve  256  kilobytes  for  initial  program  heap 

Add  4  kilobytes  to  heap  when  it  is  full 

Do  not  intercept  program  cancels 

Do  not  display  10  errors  on  workstation 


Create  a  link  map 
Retain  symbolic  data 
Retain  linkage  data 

Do  not  create  a  static  subroutine  library 
Do  not  create  a  shared  subroutine  library 
Do  not  select  subroutine  library  entry  names 
Do  not  assign  aliases  to  SSL  symbols 
Do  not  reorder  output  program  section 
Resolve  undefined  symbols  interactively 
Resolve  duplicate  section  names  interactively 
Do  not  display  in-program  screen 
Use  object  file  format  '1' 

Print  small  link  map  of  errors  or  warnings 
Do  not  select  duplicate  sections  by  date 
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APPENDIX  F  OF  THE  Ada  STANDARD 


The  only  allowed  implementation  dependencies  correspond  to 
implementation-dependent  pragmas,  to  certain  machine-dependent  conventions 
as  mentioned  in  Chapter  13  of  the  Ada  Standard,  and  to  certain  allowed 
restrictions  on  representation  clauses.  The  implementation-dependent 
characteristics  of  this  Ada  implementation,  as  described  in  this  Appendix, 
are  provided  by  the  customer.  Unless  specifically  noted  otherwise, 
references  in  this  Appendix  are  to  compiler  documentation  and  not  to  this 
report.  Implementation-specific  portions  of  the  package  STANDARD,  which 
are  not  a  part  of  Appendix  F,  are: 


package  STANDARD  is 


type  INTEGER  is  range  -2147483648  ..  2147483647; 
type  FLOAT  is  digits  15 

range  -16#0. FFFFFFFFFFFFFF#E+63  ..  16#0. FFFFFFFFFFFFFF#Et-63 ; 

type  DURATION  is  delta  2#0. 000001#  range  -131072.0  ..  131071.0; 

type  SH0RT_INTEGER  is  range  -32768  ..  32767; 

type  SH0RT_FL0AT  is  digits  6  range 

-16#0.FFFFFF#E+63  ..  16#0. FFFFFF#E+63 ; 

type  SH0RT_SH0RT_INTEGER  is  range  -128  ..  127; 


end  STANDARD; 
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IMPLEMENTATION-DEPENDENT  CHARACTERISTICS 


This  appendix  describes  the  implementation-dependent  characteristics 
o£  the  VS  Ada  compiler.  Appendix  F  is  a  required  part  of  the  LRM. 

Appendix  F  contains  the  following  sections: 

F.l  Implementation-dependent  pragmas 

F.2  Implementation-dependent  attributes 

F.3  Specification  of  the  package  SYSTEM 

F.4  Restrictions  on  representation  clauses 

F.5  Conventions  for  implementation-generated  names 

F.6  Address  clauses 

F.7  Restrictions  on  unchecked  conversions 

F.8  Implementation-dependent  characteristics  of  the  input-output 
packages 

F.9  Characteristics  of  numeric  types 

F.IO  Other  implementation-dependent  characteristics 

Throughout  this  appendix,  citations  in  square  brackets  refer  to  the 
relevant  sections  of  the  Reference  Manual  for  the  Ada  rrograa  Language 
(LRM). 
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F.1  IMPLEMENTATION-OEPENOENT  PRAGMAS 


F.1.1  Pragma  INLINE 

Pragma  IMLIHE  is  fully  supported  by  VS  Ada  with  one  exception:  a 
function  that  is  called  in  a  declarative  part  cannot  be  expanded 
inline. 


F.1.2  Pragma  INTERFACE 

Ada  programs  can  interface  ro  subprograms  written  in  assembler  or 
other  languages  through  the  predefined  pragma  IHTERFACE  [13.9]  and  the 
VS  Ada-defined  pragma  IHTERFACE_NAME.  Pragma  IHTERFACE  is  described 
in  this  section.  For  a  description  of  pragma  IHTERFACE_HAME,  see 
Section  F.1.3. 

Pragma  IHTERFACE  specifies  the  name  of  an  interfaced  subprogram  and 
the  name  of  the  programming  language  for  which  calling  and 
parameter-passing  conventions  are  generated.  The  pragma  takes  the 
form  specified  in  the  LRM: 

pragma  IHTERFACE  ( language_^name.  s\ibprogram_name) ; 

where 

language_name  is  the  name  of  the  language  whose  calling  and 
parameter-passing  conventions  are  to  be  used; 

subprogram^name  is  the  name  used  within  the  Ada  program  to  refer 
to  the  interfaced  subprogram. 

Two  language  names  are  currently  accepted  by  pragma  IHTERFACE:  CLE 
and  C.  The  language  name  CLE  refers  to  the  standard  VS  Common 
Language  Environment  calling  and  parameter-passing  convections.  You 
can  use  the  language  name  CLE  to  interface  Ada  subprograms  with 
subroutines  written  in  any  language  that  follows  the  standard  VS 
calling  conventions:  BASIC.  COBOL.  FORTRAH.  PLl.  RPGZZ.  and  some  C 
functions.  You  can  also  call  Assembler  programs  with  CLE,  although 
there  is  nothing  inherent  in  the  Assembler  language  to  expect  or 
support  this  calling  convention,  as  there  is  in  the  other  languages 
listed. 

You  must  use  the  language  name  C  when  calling  VS  C  programs  that 
expect  the  normal  C  calling  convention.  You  should,  however,  use 
pragma  IHTERFACE  CLE  to  call  C  functions  that  are  declared  with  the 
option  cle. 
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•Catling  Convantions 


For  both  CLE  and  C  pragma  INTERFACE  lanquaqa  aanaa.  th«  machin*  state 
is  saved  as  part  of  the  process  of  calling  the  interfaced  subprogram. 
This  is  accomplished  by  the  JSCZ  machine  instruction,  which  saves  the 
register  state  on  the  VS  system  stack  prior  to  jumping  to  the 
subroutine.  The  Ada  environment  is  properly  restored  from  this  save 
area  by  a  normal  return  from  the  subprogram.  From  an  Assembler 
subprogram,  this  return  must  be  performed  by  the  RT  machine 
instruction. 

The  Ada  runtime  system  treats  any  program  interruption  occurring 
during  execution  of  the  body  of  the  interfaced  subprogram  as  an 
exception  being  raised  at  the  point  of  call  of  the  subprogram.  See 
Section  S.2  for  a  discussion  of  how  non-Ada  errors  are  mapped  onto  Ada 
exceptions . 

Interfaced  subprograms  called  with  pragma  INTERFACE  may  not  issue  any 
form  of  PCEXIT  SVC.  Interfaced  subprograms  may  also  be  restricted 
from  issuing  any  form  of  CEXIT  SVC. 

Parameter-Passing  Conventions 

The  following  conventions  apply  to  both  of  the  language  names,  CLE  and 
C,  currently  accepted  by  pragma  INTERFACE: 

•  Register  1  contains  the  address  of  the  parameter  area  on  entry  to 
the  subprogram. 

•  No  consistency  checking  is  performed  between  the  subprogram 
parameters  declared  in  Ada  and  the  corresponding  parameters  of  the 
interfaced  subprogram.  It  is  your  responsibility  to  ensure 
correct  access  to  the  parameters. 

•  Formal  parameters  of  mode  out  are  not  allowed. 

For  pragma  INTERFACE  CLE,  register  1  contains  the  address  of  a 
parameter  address  list.  Each  word  in  this  list  is  an  address 
corresponding  to  a  parameter.  The  most  significant  (sign)  bit  of  the 
last  word  in  the  list  is  set  to  indicate  the  end  of  the  list. 

If  the  subprogram  is  a  function,  the  result  is  returned  in  an  area 
allocated  by  the  Ada  program  and  addressed  by  the  first  address  in  the 
parameter  address  list. 

For  formal  parameters  of  mode  in  out,  the  address  passed  is  that  of 
the  actual  parameter.  This  provides  a  true  pass  by  reference  from  Ada 
to  the  CLE  interfaced  subprogram  for  parameters  of  all  types:  scalar, 
access,  rocord,  and  array.  For  a  record  type,  the  address  in  the 
parameter  list  is  that  of  the  first  component  of  the  record.  For  an 
array  type,  the  address  in  the  parameter  list  is  that  of  the  first 
element  of  the  array. 
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Formr'  paramecvrs  oC  mod*  in  ar*  also  all  allowad  Cor  CLE  int*rCac*d 
subprograms.  For  paramaUers  of  scalar  and  accasa  typ*.  th*  addrass 
paasad  is  that  of  a  copy  of  th*  valu*  of  th*  actual  paramatar.  Th* 
actual  paramatars  ar*  tharaby  protactad  from  modification  within  th* 
intarfacad  subprogram.  For  all  othar  paramatars.  th*  addrass  passad 
is  th*  addrass  of  th*  actual  paramatar.  Coasaguantly.  nonscalar  and 
nonaccass  paramatars  to  intarfacad  subprograms  cannot  b*  protactad 
from  modification  by  th*  callad  subprogram,  avan  whan  thay  ar* 
formally  daclarad  to  b*  of  mod*  in.  It  is  your  rasponsibility  to 
ansur*  that  th*  samantics  of  th*  Ada  paramatar  modas  ar*  honorad  in 
thas*  casas. 

For  pragma  IHTERFXCE  C,  ragistar  1  again  sarvas  to  addrass  th* 
paramatar  list.  Thas*  paramatars  ar*  passad  by  valua,  howavar,  in 
accordanc*  with  tha  VS  C  param*t*r>passing  convantions.  For  all 
paramatar  typas,  th*  valuas  of  th*  actual  paramatars  ar*  passad  in  th* 
paramatar  araa. 

Formal  paramatars  of  mod*  in  are  allowed  for  all  typas  of  actual 
parameters:  scalar,  access,  record,  and  array.  For  a  scalar  or 
access  paramatar,  th*  value  of  the  actual  paramatar  is  stored  in  th* 
parameter  area.  For  a  record  paramacar,  a  copy  of  th*  entire  record 
is  stored  in  tha  parameter  area.  For  an  array  paramatar,  tha  address 
of  th*  array  is  stored  in  th*  paramatar  araa,  sine*  th*  valu*  of  an 
array  in  a  C  expression  is  simply  th*  addrass  of  th*  first  alamant  of 
tha  first  dimension  of  th*  array. 

Because  array  parameters  to  C  interfaced  subprograms  ar*  passad  by 
addrass,  thay  cannot  b*  protactad  from  modification  by  th*  callad 
subprogram,  avan  whan  thay  ar*  formally  daclarad  to  b*  of  mod*  in.  It 
is  your  rasponsibility  to  ansur*  that  th*  samantics  of  th*  hda 
paramatar  mod*  ar*  honorad  in  this  case. 

A  formal  paramatar  of  mod*  in  out  is  not  allowed  for  any  scalar, 
access  or  record  typ*  but  is  allowed  for  an  array  typ*  since  an  array 
paramatar  is  passed  by  its  addrass. 

If  th*  C  subprogram  is  daclarad  and  callad  as  a  function,  r*gis*’:er  0 
is  used  to  return  th*  result.  Scalar  and  access  valuas  ar*  returned 
in  ganaral  ragistar  0.  Floating  point  valuas  ar*  raturnad  in  floating 
point  register  0.  Record  valuas  ar*  raturnad  by  addrass  in  ganaral 
register  0.  Array  values  ar*  not  supported,  sine*  VS  C  does  not  allow 
a  function  to  return  an  array  result. 

Pragma  INTERFACE  C  lets  you  daclare  and  call  a  C  subprogram  as  a 
procedure .  It  is  your  rasponsibility  to  do  so  only  where  appropriate; 
specifically,  whan  calling  a  C  function  that  is  declared  in  C  to  be  of 
typ*  VOID. 
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Parameter  Representations 


This  ssction  describes  the  representation  of  values  of  the  types  that 
can  be  passed  as  parameters  to  an  interfaced  subprogram.  The 
discussion  assumes  that  you  have  not  used  representation  clauses  to 
change  the  default  representations  of  the  types  involved.  The  effect 
of  representation  clauses  on  the  representation  of  values  is  described 
in  Section  F.4. 

The  following  types  can  be  passed  as  parameters  to  an  interfaced 
subprogram: 

Integer  typea  [3.5.4]  —  Ada  integer  types  are  represented  in  two's 
complement  form  and  occupy  3  (SHORT_SHORT_IMTEGER) ,  16 
(SHORT_INTEGER) ,  or  32  (INTEGER)  bits. 

Boolean  types  [3.5.3]--  Ada  Boolean  types  are  represented  as  8-bit 
values:  FALSE  is  represented  by  the  value  0;  TRUE,  by  the  value  1. 

Enumeration  types  [3.5.1]--  Ada  enumeration  types  are  represented 
internally  as  unsigned  values  corresponding  to  their  positions  in 
the  list  of  enumeration  literals  that  defines  the  type.  The  first 
literal  in  the  list  has  the  value  0. 

An  enumeration  type  can  include  a  maximum  of  2**31  values. 
Enumeration  types  with  256  elements  or  fever  are  represented  in 
a  bits;  those  with  256  to  65536  (2**16)  elements  are  represented 
16  bits;  all  others  are  represented  in  32  bits.  Accordingly,  th 
Ada  predefined  type  CHARACTER  [3.5.2]  is  represented  in  8  bits, 
using  the  standard  ASCII  codes  [C]. 

Floating  point  types  [3.5.7,  3.5.8]  —  Ada  floating  point  types 
occupy  32  (SH0RT_FL0AT)  or  64  (FLOAT)  bits  and  are  held  in  VS  (short 
or  long)  format. 

Fined  point  types  [3.5.9,  3.5.10]  —  Ada  fixed  point  types  are 
managed  by  the  compiler  as  the  product  of  a  signed  mantissa  and  a 
constant  small.  The  mantissa  is  implemented  as  a  16-  ur  32-bit 
integer  value.  Small  is  a  compile-time  quantity  that  is  the  power 
of  two  equal  or  immediately  inferior  to  the  delta  specified  in  the 
declaration  of  the  type. 

The  attribute  MANTISSA  is  defined  as  the  smallest  number  such  that 
2  **  MANTISSA  >s  max  ( abs(upper_bound) ,  abs  ( lower_bound) )  /  small 
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Th*  sis*  of  a  £ix*d  point  typ*  is 


HAHTISSA  Sis* 

1  ..15  16  bits 

16  ..31  32  bits 

Fixtd  point  typos  requiring  a  MANTISSA  gr*at*r  than  31  ar*  not 
supported. 

Access  types  [3.8]  --  Values  of  Ada  access  types  are  represented 
internally  by  th*  31-bit  address  of  th*  designated  object  held  in  a 
32-bit  word.  You  should  not  alter  any  bits  of  this  word,  even  those 
that  are  ignored  by  the  architecture  on  which  the  program  is 
running.  Th*  value  0  is  used  to  represent  null. 

Array  types  [3.6]  --  Th*  elements  of  an  array  are  allocated  by  row. 
When  an  array  is  passed  as  a  parameter  to  an  interfaced  subprogram, 
the  usual  consistency  checking  between  the  array  bounds  declared  in 
the  calling  program  and  the  subprogram  is  not  enforced.  Therefore, 
it  is  your  responsibility  to  ensure  that  the  subprogram  does  not 
violate  th*  bounds  of  the  array. 

Values  of  the  predefined  type  STRING  [3.6.3]  are  arrays  and  are 
passed  in  th*  same  way  as  the  values  of  any  other  array  type. 
Elements  of  a  string  are  represented  in  8  bits,  using  the  standard 
ASCII  codes. 

Record  types  [3«7]  --  Components  erf  a  record  ar*  aligned  on  their 
natural  boundaries  (e.g.,  INTEGER  is  aligned  on  a  word  boundary), 
and  the  compiler  may  reorder  the  components  to  minimize  th*  total 
size  of  objects  of  th*  record  typ*.  If  a  record  contains 
discriminants  or  components  having  a  dynamic  size,  implicit 
components  may  be  added  to  th*  record.  Thus,  th*  default  layout  of 
the  internal  structure  of  th*  record  cannot  be  inferred  directly 
from  its  Ada  declaration.  It  is  therefor*  recommended  that  you  us* 
a  representation  clause  to  control  th*  layout  of  any  record  typ* 
whose  values  are  to  be  passed  to  interfaced  subprograms. 

RMtrictions  on  Intorf acod  Subprograms 

Refer  to  Chapter  5  for  a  description  of  th*  restrictions  on  interfaced 
subprograms. 
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F.1.3  Pragma  INTERFACE.NAME 


Pragma  IHTERFACE^NAME  associates  the  name  of  an  interfaced  subprogram, 
as  declared  in  Ada,  with  its  name  in  its  language  of  origin.  If 
pragma  INTERFAC£_NAME  is  not  used,  then  the  two  names  are  assumed  to 
be  identical. 

Pragma  INTERFACE_NAME  takes  the  form 

pragma  INTERFACE_NAME  ( subprogram_name,  string_literal ) ; 
where 

subprogram_name  is  the  name  used  within  the  Ada  program  to  refer 
to  the  interfaced  subprogram; 

string_literal  is  the  name  by  which  the  interfaced  subprogram  is 
rr^ferred  to  at  link  time. 

The  use  of  IMTERFAC£_HAME  is  optional;  you  need  not  use  it  if  a 
subprogram  has  the  same  name  in  Ada  as  it  has  in  its  language  of 
origin.  INTERFACE_OAME  is  useful  if,  for  example,  the  name  of  the 
subprogram  in  its  original  language  contains  characters  that  are  not 
permitted  in  Ada  identifiers.  Although  Ada  identifiers  can  contain 
letters,  digits,  and  underscores,  the  VS  Linker  limits  external  name-- 
to  the  letters  A-Z;  the  digits  0-9;  and  the  symbols  S,  9,  and  i. 

Thus,  only  these  characters  are  permitted  in  the  string_literal 
argument  of  the  pragma  rHTERFACE_NAME . 

Pragma  INTERFACE_NAME  is  allowed  at  the  same  places  in  an  Ada  program 
as  pragma  INTERFACE  [13.9}.  However,  INTERFACE_NAME  must  always  occur 
after  the  pragma  INTERFACE  declaration  for  the  interfaced  subprogram. 

In  order  to  conform  to  the  naming  conventions  of  the  VS  Linker,  the 
link-time  name  of  an  interfaced  subprogram  is  truncated  to 
32  characters  and  converted  to  upper  case. 

Example 

package  SAMPLE_OATA  is 

function  PROCESS_S AMPLE  (X; INTEGER)  return  INTEGER; 
private 

pragma  INTERFACE  (ASSEMBLER,  PROCESS^SAMPLE) ; 
pragma  IirrERFACE_NAME  ( PROCESS_SAMPLE ,  "PSAMPLE*’ )  ; 
end  SAMPLE  DATA: 
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F.1.4  Other  Pragmas 


Pragmas  IMPROVE  and  PACE  —  Thasa  pragmas  are  discussed  in  detail  in 
section  r.4. 

Pragma  PRIORITY  —  Pragma  PRIORITY  is  accepted  vith  Che  range  of 
priorities  running  from  1  to  1  (see  the  definition  of  the  predefined 
package  SYSTEM.  Section  F.3).  The  undefined  priority  (no  pragma 
PRIORITY)  is  treated  as  leas  than  any  defined  priority  value  (see 
Appendix  B) . 

Pragma  SUPPRESS  --  You  can  substitute  the  compiler  option  CHECKS  for 
the  pragma  SUPPRESS  to  suppress  all  checks  in  a  compilation. 

The  following  pragmas  have  no  effect: 

•  CONTROLLED 

•  MEMORY_SIZE 

•  OPTIMIZE 

•  STORAGE_UNIT 

•  SYSTEM_NAME 

Note  that  all  access  types  are  implemented  by  default  as  controlled 
collections,  as  described  in  [4.8]  (see  Section  f.lO.l). 


F.2  IMPLEMENTATION-OEPENOENT  ATTRIBUTES 

In  addition  to  the  representation  attributes  described  in  the  LRM 
[13.7.2  and  13.7.3].  VS  Ada  provides  the  following  attributes: 

T'VARXANT_I1IDKZ.  C*  ABRAY_ORSCRZPTOR,  T'ReCORD_SZZB. 
C'RECOSO_OBSCBlPTOB  —  These  attributes,  which  are  used  in  record 
representation  clauses,  are  described  in  Section  F.5. 

T'DKSCRIPTOB_SIZK  .  T'IS_ABBAY  —  These  attributes  are  described  in 
Section  F.2.1. 

VS  Ada  imposes  certain  limitations  on  the  use  of  the  attribute 
ADDRESS.  These  limitations  are  described  in  Section  F.2. 2. 
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P.2.1 


Th«  Attributes  T'OESCRIPTOR  SIZE  and  T'IS.ARRAY 


The  attributes  T'OESCRIPTOS_SIZE  and  T'IS_ARRAY  are  described  as 
follows: 

T' DESCRIPTOR'S I ZB  —  For  a  prefix  T  that  denotes  a  type  or  subtype, 
this  attribute  yields  the  size  (in  bits)  required  to  hold  a 
descriptor  for  an  object  of  the  type  T,  allocated  on  the  heap  or 
written  to  a  file.  If  T  is  constrained,  T‘DESCRIPTOR_SIZE  yields 
the  value  0. 

T*IS_ARRAY  --  For  a  prefix  T  that  denotes  a  type  or  subtype,  this 
attribute  yields  the  value  TRUE  if  T  denotes  an  array  type  or  an 
array  subtype;  otherwise,  it  yields  the  value  FALSE. 

P.2.2  Limitations  on  the  Us«  of  tho  Attribute  ADDRESS 

The  attribute  ADDRESS  is  implemented  for  all  prefixes  that  have 
meaningful  addresses.  The  following  entities  do  not  have  meaningful 
addresses;  each  causes  a  compilation  warning  if  used  as  a  prefix  to 
ADDRESS: 

•  A  constant  that  is  implemented  as  an  immediate  value;  that  is,  one 
for  which  no  space  is  allocated 

•  A  package  specification  that  is  not  a  library  unit 

•  A  package  body  that  is  not  a  library  unit  or  subunit 
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F.3 


SPECIFICATION  OF  THE  PACKAGE  SYSTEM 


package  SYSTEM  is 

type  NAME  is  (WAUG^VS); 

SYSTEM_NAME  ;  constant  NAME  ;=  NAME'FIRST; 
MIN^INT  :  constant  -(2**31); 

MAX^INT  ;  constant  2**31-1; 

MEMORY_SIZE  :  constant  :=  2**24; 

type  ADDRESS  is  range  MIN_rNT  . .  MXX^INT; 

STORATE_UNIT  ;  constant  :=  3; 

MAX_DIGITS  :  constant  ;=  15; 

MAx'mANTISSA  :  constant  :=  31; 

FINE_OELTA  :  constant  :s  2#1.0#e-31; 

TICK  :  constant  :=  0-01; 

mJLL_ADDRESS  ;  constant  ADDRESS  0; 

subtype  PRIORITY  is  INTEGER  range  1  . .  1; 

PROGRAM^CANCEL  :  exception; 

end  SYSTEM; 


F.4  RESTRICTIONS  ON  REPRESENTATION  CLAUSES 

this  section  explains  how  objects  are  represented  and  allocated  by  the 
VS  Ada  compiler  and  how  you  can  use  representation  clauses  to  control 
the  representation  and  allocation  of  objects. 

As  the  representation  of  an  object  is  closely  connected  with  its  type, 
this  section  addresses  successively  the  representation  of  enumeration, 
integer,  floating  point,  fixed  point,  access,  task,  array,  and  record 
types.  For  each  class  of  type,  the  representation  of  the 
corresponding  objects  is  described. 

With  the  exception  of  array  and  record  types,  the  description  of  each 
type  is  independent  of  the  others.  To  understand  the  representation 
of  an  array  type  or  of  a  record  type,  you  must  first  understand  the 
representation  of  its  components. 
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Apart  from  implftnientation-d«f in«d  praqfinas,  Ada  provides  three  means  to 
control  the  size  of  objects: 

•  A  size  specification  can  be  used  to  control  the  size  of  any  objec;:. 

•  The  predefined  pragma  PACK  can  be  used  to  control  the  size  of  an 
array,  an  array  component,  a  record,  or  a  record  component. 

•  A  record  representation  clause  can  be  used  to  control  the  size  of 
a  record  or  a  record  component. 

The  sections  that  follow  describe  the  effect  of  size  specifications  or. 
each  class  of  type;  Sections  F.4.7  and  F.4.8  describe  the  interaction 
among  size  specifications,  packing,  and  record  representation  clauses 
on  array  and  record  types. 

Representation  clauses  on  derived  record  ty'pes  or  derived  task  types 
are  not  supported,  and  size  representation  clauses  are  not  supported 
on  types  derived  from  private  types  when  they  are  declared  outside  t.he 
private  part  of  the  defining  package. 

F.4.1  Enumeration  Types 


Internal  codes  of  enumeration  literals 

As  described  in  the  LRM  [13.3],  you  can  ise  an  enumeration 
representation  clause  to  specify  the  value  of  the  internal  code 
associated  with  an  enumeration  literal.  Enumeration  representation 
clauses  are  fully  implemented. 

Since  internal  codes  must  be  machine  integers,  the  internal  codes 
specified  in  an  enumeration  representation  clause  must  be  in  the  range 
-23^  231-1. 

If  you  do  not  specify  an  enumeration  representation  clause,  the 
internal  code  associated  with  an  enumeration  literal  is  the  position 
number  of  the  enumeration  literal.  Thus,  for  an  enumeration  type  wit.h 
n  elements,  the  internal  codes  are  the  integers  0,  1,  2,  ..  n-1. 


Encoding  of  enumeration  values 

In  the  program  generated  by  the  compiler,  an  enumeration  value  is 
always  represented  by  its  internal  code. 
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Minimum  size  of  an  enumeration  subtype 

The  trinitnum  size  of  an  en'omeration  subtype  is  the  minimum  number  of 
bits  necessary  to  represent  the  internal  codes  of  the  subtype  values 
in  normal  binary  form. 

If  a  static  subtype  has  a  null  range,  its  minimum  size  is  1. 

Otherwise,  if  m  and  M  are  the  values  of  the  internal  codes  associated 
with  the  first  and  last  enumeration  values  of  the  subtype,  then  its 
minimum  size  L  is  determined  as  follows: 

For  m  >a  0.  L  is  the  smallest  positive  integer  such  that  M  <b  2^-1. 

For  m  <  0.  L  is  the  smallest  positive  integer  such  that  -Z^~^  <s  m  and 
M  <=  2‘^-i-l. 

For  example: 

type  COLOR  is  (GREEN,  BLACK.  WHITE,  RED,  BLUE,  YELLOW); 

--  The  minimum  size  of  COLOR  is  3  bits. 

subtype  BLACK_AND_WHITE  is  COLOR  range  BLACK  ..  WHITE; 

--  The  minimum  size  of  BLACK_AND_WHITE  is  2  bits. 

subtype  BLACK_OR_WHITE  is  aLACK_AND_WHITE  range  X  . .  X; 

--  Assuming  that  X  is  not  static,  the  minimum  size  of  BLACK__OR_WHITE 
--  is  2  bits  (the  same  as  the  minimum  size  of  the  static  type  mark 
--  BLACK_AND_WHITE) . 

Size  of  an  enumeration  subtype 

You  can  specify  the  size  of  an  enumeration  type  and  each  of  its 
subtypes  in  the  length  clause  of  a  size  specification.  The  length 
clause  also  determines  the  size  of  a  first-named  subcype.  You  must  of 
course  specify  a  value  greater  than  or  equal  to  the  minimum  size  of 
the  type  or  subtype. 
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For  example: 


type  EXTENDED  is 

(  —  The  usual  American  ASCII  characters. 


NUL, 

SOH, 

STX, 

ETX, 

EOT, 

ENQ, 

ACK, 

BEL, 

BS, 

HT, 

LF, 

VT, 

FF, 

CR, 

SO, 

SI, 

OLE. 

DCl, 

DC2, 

DC3, 

DC4, 

NAK, 

SYN, 

ETB, 

CAN, 

EM, 

SUB, 

ESC, 

FS, 

GS, 

RS, 

US, 

•  1 

# 

•  1  * 

t 

*  t(  t 

a 

•/»*, 

•$• , 

•%*, 

'  S'  , 

•  1  • 

(  ’  . 

*  )  ■  , 

*  *  *  * 

t  * 

a  a 

t  1 

••  a 

»  * 

'  /  • , 

'O'  , 

■1'  , 

'2  •  , 

•3'. 

•4’  , 

•S', 

'  6  '  , 

'7  '  , 

’8'  . 

'9'  , 

1  ,  « 

#  / 

““  a 

'  >  '  , 

'  ?  *  / 

■A'  , 

‘B*  , 

•c , 

•D'  , 

•E', 

'  F'  , 

'G  , 

■H’  . 

■  I  ’  , 

•  J'  , 

■K'  , 

•L', 

•M', 

•N'  , 

■O'  , 

•P'  , 

•Q‘ . 

■R'  , 

•S'  , 

•T*, 

*U', 

•v , 

•w , 

■X*  , 

'Y*  , 

■Z’  , 

t  * 

a 

f  ( 

•  1 

'a'  , 

■b* , 

'  c  * , 

•d'. 

'e* , 

'  c ' , 

■g'« 

■h'  , 

'  i '  , 

’  j  '  » 

•k'  . 

•  1*  , 

'm'  , 

'  n '  , 

■o'. 

‘P’  « 

■q'  / 

‘  r  •  , 

's'. 

•f  , 

'  u'  , 

•  v , 

'  W  *  , 

'  X  '  , 

•y' , 

'  2  '  , 

•I’. 

»  ^  1 

a 

DEL, 

--  Extended  characters 
LEFT_ARROW. 

RIGHT_ARROW, 

UPPER~ARROW. 

lower'arrow. 

UPPER~LEFT_CORNER , 

upper"right_corner , 
lower~right”corner , 
lower”left_corner . 

. . . ) ; 

Cor  EXTENDED 'SIZE  use  8; 

--  The  size  of  type  EXTENDED  will  be  one  byte.  Its  objects  will  be 
--  represented  as  unsigned  3-bit  integers. 

The  compiler  Cully  implements  size  specifications.  As  enumeration 
values  are  represented  as  integers,  however,  the  length  you  speciCy 
cannot  be  greater  than  32  bits,  the  size  of  the  largest  predefined 
integer  on  the  VS. 

If  you  do  not  use  a  size  specification  for  an  enumeration  type  or 
first-named  subtype,  the  objects  of  that  type  or  subtype  are 
represented  as  signed  integers  if  the  internal  code  associated  with 
the  first  enumeration  value  is  negative  and  as  unsigned  integers 
otherwise.  VS  Ada  provides  3-,  IS-  and  32-bit  integers;  the  compiler 
automatically  selects  the  smallest  machine  integer  that  can  hold  each 
of  the  internal  codes  of  the  enumeration  type  or  subtype.  Thus,  the 
size  of  the  enumeration  type  and  any  of  its  subtypes  is  8,  16  or 
32  bits. 
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Size  of  Che  objects  of  an  enumeration  auhtype 

Provided  it  is  not  constrained  by  a  record  component  clause  or  a 
pragma  PACK,  an  object  of  an  enumeration  subtype  is  the  same  size  as 
its  subtype. 

Alignment  of  an  enumeration  subtype 

An  enumeration  subtype  is  byte-aligned  if  the  size  of  the  subtype  is 
less  than  or  equal  to  8  bits,  halfword-aligned  if  the  size  of  the 
subtype  is  less  than  or  equal  to  16  bits,  and  word-aligned  otherwise. 

Address  of  an  object  of  an  enumeration  aubtype 

Provided  its  alignment  is  not  constrained  by  a  record  representation 
clause  or  a  pragma  PACK,  the  address  of  an  object  of  an  enumeration 
subtype  is  a  multiple  of  the  alignment  of  the  corresponding  subtype. 


F.4.2  Integer  Types 


Predefined  integer  types 

The  VS  provides  three  predefined  integer  types: 

type  SHORT_SHORT_INTEGER  is  range  -2**07  ..  2**07-l; 

type  SHORt“inTEGER  is  range  -2**15  ..  2**15-1; 

type  INTEGER  is  range  -2**31  ..  2**31-1; 

Selection  of  the  parent  of  an  integer  type 

An  integer  type  declared  as 

type  T  is  range  L.  ..  R; 

is  implicitly  derived  from  either  the  SHORT_INTEGER  or  INTEGER 
predefined  integer  type.  The  compiler  automatically  selects  the 
predefined  integer  type  with  the  shortest  range  containing  the  values 
L  to  R  inclusive.  Note  that  the  the  compiler  never  automatically 
selects  the  SHORT_SHORT_INTEGER  representation. 

Encoding  of  integer  values 

In  the  program  generated  by  the  compiler,  integer  values  are 
represented  in  binary  code  in  a  conventional  two's  complement  form. 
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Nininun  size  of  an  integer  subtype 

The  minimuni  size  oC  an  integer  subtype  is  the  minimum  number  of  bits 
necessary  to  represent  the  internal  codes  of  the  subtype  values  in 
normal  binary  form  (that  is,  in  an  unbiased  form  that  includes  a  sign 
bit  only  if  the  range  of  the  subtype  includes  negative  values). 

If  a  static  subtype  has  a  null  range,  its  minimum  size  is  1. 

Otherwise,  if  m  and  M  are  the  lower  and  upper  bounds  of  the  subtype, 
then  its  minimum  size  L  is  determined  as  follows: 

For  m  >=  0,  L  is  the  smallest  positive  integer  such  that  M  <=  2^-1; 
for  m  <  0,  L  is  the  smallest  positive  integer  such  that  -2^“^  <=  m  and 
M  <=  2^‘^-l. 

For  example: 

subtype  S  is  INTEGER  range  0  ..  7; 

--  The  minimum  size  of  is  3  bits. 

subtype  D  is  S  range  X  ..  Y: 

--  Assuming  that  X  and  Y  are  not  static,  the  minimum  size  of 
--  D  is  3  bits  (the  same  as  the  minimum  size  of  the  static  type 
--  mark  S ) . 

Size  of  an  integer  subtype 

The  sizes  of  the  predefined  integer  types  SHORT_SHORT_INTEGER. 
SHORT_ItrrEGER,  and  INTEGER  are  8,  16  and  32  bits,  respectively. 

You  can  specify  the  size  of  an  integer  type  and  each  of  its  subtypes 
in  the  length  clause  of  a  size  specification.  The  length  clause  also 
determines  the  size  of  a  first-named  subtype.  You  must  of  course 
specify  a  value  greater  than  or  eguaJL  to  the  minimum  size  of  the  type 
Of  subtype. 

For  example: 

type  S  is  range  80  ..  100; 
for  S'SIZE  use  32; 

—  S  is  derived  from  SHORT_INTEGER,  but  its  size  is  32  bits 
--  because  of  the  size  specification. 

type  J  is  range  0  ..  255; 
for  J'SIZE  use  8; 

--  J  is  derived  from  SHORT_INTEGER,  but  its  size  is  8  bits  because 
--  of  the  size  specification. 

type  N  is  new  J  range  80  . .  100; 

--  M  is  indirectly  derived  from  SHORT_INTEGER,  but  its  size  is  8  bits 
--  because  N  inherits  the  size  specification  of  J. 
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The  compiler  implements  size  specifications.  As  integers  are 
implemented  using  machine  integers,  however,  the  length  specified 
cannot  be  greater  than  32  bits. 

If  you  do  not  use  a  sise  specification  for  an  integer  type  or  its 
first-named  subtype  (if  any),  the  size  of  the  integer  and  any  of  its 
subtypes  is  the  size  of  the  predefined  type  from  which  it  derives, 
directly  or  indirectly. 

For  example: 

type  S  is  range  80  ..  100; 

--  S  is  derived  from  SHORT_INTEGER;  its  size  is  16  bits, 
type  J  is  range  0  ..  65535; 

—  J  is  derived  from  INTEGER;  its  size  is  32  bits. 

type  N  is  new  J  range  80  ..  100; 

N  is  indirectly  derived  from  INTEGER;  its  size  is  32  bits. 

Size  of  the  objects  of  an  integer  subtype 

Provided  it  is  not  constrained  by  a  record  component  clause  or  a 
pragma  PACK,  an  object  of  an  integer  subtype  is  the  same  size  as  its 
subtype. 

Alignment  of  an  integer  subtype 

An  integer  subtype  is  byte-aligned  if  the  size  of  the  subtype  is  less 
than  or  equal  to  8  bits,  halfword-aligned  if  the  size  of  the  subtype 
is  leas  than  or  equal  to  16  bits,  and  word-aligned  otherwise. 

Address  of  an  object  of  an  integer  subtype 

Provided  its  alignment  is  not  constrained  by  a  record  represrintation 
clause  or  a  pragma  PACK,  the  address  of  an  object  of  an  integer 
subtype  is  a  multiple  of  the  alignment  of  the  corresponding  subtype. 


F.4.3  Floating  Point  Typos 

Predefined  floating  point  types 

VS  Ada  provides  two  predefined  floating  point  types: 
type  SHORT_FLOAT  is 

digits  6  range  -2.0**252  *( 1.0-2. 0**-24)  ..  2.0**252*  (1 . 0-2 .0**-24  ) 
type  FLOAT  is 

digits  15  range  -2.0**252  *(  1.0-2 . 0**-56)  ..2.0**252e  ( 1 . 0-2 .0**-56 ) 
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Selection  of  the  parent  of  a  floating  point  type 

X  Cloatiug  point  type  declared  as 

type  t  is  digits  D  [range  L  ..  R]; 

is  implicitly  derived  from  a  predefined  floating  point  type.  The 
compiler  automatically  selects  the  smallest  predefined  floating  point 
type  whose  number  of  digits  is  greater  than  or  equal  to  D  and  that 
contains  the  values  L  and  R. 

fTncodiny  of  floating  point  values 

In  the  program  generated  by  the  compiler,  floating  point  values  are 
represented  using  VS  data  formats  for  single-precision  or 
double-precision  floating  point  values,  as  appropriate. 

Values  of  the  predefined  type  SHORT_FLOXT  are  represented  using  the 
single  precision  format;  values  of  the  predefined  type  FLOXX  are 
represented  using  the  double  precision  format.  The  values  of  any 
other  floating  point  type  are  represented  in  the  same  format  as  the 
values  of  the  predefined  type  from  which  it  derives,  directly  or 
indirectly. 

fiinimum  size  of  a  floating  point  subtype 

The  minimum  size  of  a  floating  point  subtype  is  32  bits  if  its  base 
type  is  SHORT_FLOXT  or  a  type  derived  from  SHORT^FLOXT  and  64  bits  if 
its  base  type  is  FLOXT  or  a  type  derived  from  FLOXT. 

Size  of  a  floating  point  sudtype 

The  sizes  of  the  predefined  floating  point  types  SHORT_FLOXX  and  FLOXT 
are  32  and  64  bits,  respectively. 

The  size  of  a  floating  point  type  and  the  size  of  any  of  its  subtypes 
is  the  size  of  the  predefined  type  from  which  it  derives,  directly  or 
indirectly. 

The  only  size  you  can  specify  for  a  floating  point  type  or  first-named 
subtype  in  a  size  specification  is  its  usual  size  (32  or  64  bits). 

Size  of  the  objects  of  a  floating  point  subtype 

Xn  object  of  a  floating  point  subtype  has  the  same  size  as  its  subtype. 
Alignment  of  a  floating  point  subtype 

A  floating  point  subtype  is  word-aligned  if  its  size  is  32  bits  and 
double  word-aligned  otherwise. 
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Kddrmas  oi  «n  objmct  of  a  floating  point  subtgpm 

Provided  its  aligninant  is  not  coastrainad  by  a  record  representation 
clause  or  a  pragma  PACK,  the  address  of  an  object  of  a  floating  point 
subtype  is  a  multiple  of  the  alignment  of  the  corresponding  subtype. 


F.4.4  Fixed  Point  Types 


Small  of  a  fixad  point  type 

You  can  specify  the  value  of  small  in  the  length  clause  of  a  size 
specification.  The  value  you  specify  must  be  a  power  of  two. 

If  you  do  not  use  a  size  specification  to  specify  small  of  a  fixed 
point  type,  then  the  value  of  small  is  determined  by  the  value  of 
delta,  as  defined  by  the  LRM  [3.5.9]. 

Predefined  fixed  point  types 

VS  Ada  provides  a  set  of  anonymous  predefined  fixed  point  types  of  the 
form 

type  FIXED  is  delta  D  range  (-2**15-1)*S  ..  (2**15)*S; 
for  FIXED ‘SMALL  use  S; 

type  LONG^riXEO  is  delta  D  range  (-2**31-1)*S  ..  (2**3l)eS; 
for  L0NG_F1XED' SMALL  use  S; 

where  0  is  any  real  value  and  S  is  any  power  of  two  less  than  or  equal 

CO  D. 

Selection  of  the  parent  of  a  fixed  point  type 
A  fixed  point  type  declared  as 
type  T  is  delta  D  range  L  ..  R; 
optionally,  with  a  small  specification 
for  T' SMALL  use  S; 

is  implicitly  derived  from  a  predefined  fixed  point  type.  The 
compiler  automatically  selects  the  predefined  fixed  point  type  whose 
small  and  delta  are  the  same  as  the  small  and  delta  of  T  and  whose 
range  is  the  shortest  that  includes  the  values  L  and  R. 
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Encoding  of  fixed  point  values 

In  the  progrant  generated  by  the  compiler,  a  safe  value  V  ot  fixed 
point  subtype  F  is  represented  as  the  integer 

V  /  F’ BASE ’SMALL 

Minimum  size  of  a  fixed  point  subtgpe 

the  minimuin  size  of  a  fixed  point  subtype  is  the  minimum  number  of 
binary  digits  necessary  to  represent  the  values  of  the  range  of  the 
subtype  using  the  small  of  the  base  type  (that  is,  in  an  unbiased  form 
chat  includes  a  sign  bit  only  if  the  range  of  the  subtype  includes 
negative  values). 

If  a  static  subtype  has  a  null  range,  its  minimum  size  is  1. 

Otherwise,  if  s  and  S  are  the  bounds  of  the  subtype,  and  if  i  and  I 
are  the  integer  representations  of  m  and  M  (the  smallest  and  greatest 
model  numbers  of  the  base  type  such  that  s  c  m  and  M  <  S),  then  the 
minimum  size  L  is  determined  as  follows: 

For  i  )=  0.  L  is  the  smallest  positive  integer  such  that  I  <=  2^-1: 

Cor  i  <  0.  L  is  the  smallest  positive  integer  such  that  -2^*^  <=  i  and 
I  <=  2^-^-l, 

For  example: 

type  F  is  delta  2.0  range  0.0  ..  500.0; 

The  minimum  size  of  F  is  8  bits. 

subtype  S  is  F  delta  16.0  range  0.0  ..  250.0; 

--  The  minimum  size  of  S  is  7  bits. 

subtype  0  is  S  range  X  ..  1: 

--  Assuming  that  X  and  Y  are  not  static,  the  minimum  size  of  D  is 
--  7  bits  (the  same  as  the  minimum  size  of  its  type  mark  S). 

Size  of  a  fixed  point  subtype 

The  sizes  of  the  sets  of  predefined  fixed  point  types  FIXED  and 
L0NG_FIX£0  are  16  and  32  bits,  respectively. 

You  can  specify  the  size  of  a  fixed  point  type  and  each  of  its 
subtypes  in  the  length  clause  of  a  size  specification.  The  length 
clause  also  determines  the  size  of  a  first-named  subtype.  You  must  of 
course  specify  a  value  greater  than  or  equal  to  the  minimum  size  of 
the  type  or  subtype. 
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For 

typ*  F  is  delta  9.01  rang*  0.0  ..  2.0; 

(or  F'SIZE  usa  32; 

—  F  is  derived  from  a  16  bit  predefined  fixed  type,  but  its  size  is 

—  32  bits  because  of  the  size  specification. 

type  L  is  delta  0.01  ranqe  0.0  ..  300.0; 
for  F'SIZE  use  16; 

—  F  is  derived  from  a  32  bit  predefined  fixed  type,  but  its  size  is 

—  16  bits  because  of  the  size  specification.  The  size 

—  specification  is  legal  since  the  range  contains  no  negative  values 

—  and  therefore  no  sign  bit  is  required. 

type  H  is  new  F  range  0.8  ..  1.0; 

—  H  is  indirectly  derived  from  a  16  bit  predefined  fixed  type,  but 

—  its  size  is  32  bits  because  H  inherits  the  size  specification  of 

—  r. 


The  VS  Ada  compiler  implements  size  specifications.  As  fixed  point 
objects  are  represented  using  machine  integers,  however,  the  length 
specified  cannot  be  greater  than  32  bits. 

If  you  do  not  use  a  size  specification  for  a  fixed  point  type  or  its 
first-named  subtype,  the  size  of  the  fixed  point  type  and  any  of  its 
subtypes  is  the  size  of  the  predefined  type  from  which  it  derives, 
directly  or  indirectly. 


For  example: 


type  F  is  delta  0.01  range  0.0  ..  2.0; 

—  F  is  derived  from  a  16  bit  predefined  fixed  type;  its  size  is 

—  16  bits. 

type  L  is  delta  0.01  range  0.0  ..  300.0; 

—  (,  is  derived  from  a  32  bit  predefined  fixed  type;  its  size  is 

—  32  bits. 


type  N  is  new  L  range  0.0  ..  2.0; 

--  K  is  indirectly  derived  from  a  32  bit  predefined  fixed  type;  its 
—  size  is  32  bits. 


Size  o£  the  objmets  of  a  fixtd  point  subtypm 

Provided  it  is  not  constrained  by  a  record  component  clause  or  a 
pragma  PACK,  an  object  of  a  fixed  point  type  is  the  same  size  as  its 
subtype. 
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Aiignaicnc  of  a  fixmd  point  subtype 

K  fixad  point  subtyp*  ia  byt«-align«d  if  its  sis*  is  lass  than  or 
agual  to  8  bits,  halfvord-alignad  if  the  size  of  the  subtype  is  less 
than  or  equal  to  16  bits,  and  word-aligned  otherwise. 

Address  of  an  object  of  a  fixed  point  subtype 

Provided  its  alignment  is  not  constrained  by  a  record  representation 
clause  or  a  pragma  PACK,  the  address  of  an  object  of  a  fixed  point 
subtype  is  a  multiple  of  the  alignment  of  the  corresponding  subtype. 


F.4.5  Access  Types 

Collection  Size 

As  described  in  the  LRM  [13.2],  you  can  use  the  length  clause  of  a 
size  specification  to  indicate  the  amount  of  storage  space  to  be 
reserved  for  the  collection  of  an  access  type.  The  compiler  fully 
implements  this  kind  of  specification. 

If  you  do  not  specify  collection  size  for  an  access  type,  no  storage 
space  is  reserved  for  its  collection;  the  value  of  the  attribute 
ST0RAGE_SI2E  is  then  0. 

Minimum  size  of  an  access'  subtype 

The  minimum  size  of  an  access  subtype  is  32  bits. 

Size  of  an  access  subtype 

The  size  of  an  access  subtype  is  32  bits,  the  same  as  its  minimum  size. 

The  only  size  you  can  specify  for  an  access  type  in  a  size 
specification  is  its  usual  size  (32  bits). 

Size  of  the  objects  of  an  access  subtype 

An  object  of  an  access  subtype  is  the  same  size  as  its  subtype;  thus, 

an  object  of  an  access  subtype  is  always  32  bits. 

Alignment  of  an  access  subtype 

An  access  subtype  is  always  word-aligned. 

Address  of  an  object  of  an  access  subtype 

Provided  its  alignment  is  not  constrained  by  a  record  representation 
clause  or  a  pragma  PACK,  the  address  of  an  object  of  an  access  subtype 

is  always  on  a  word  boundary  since  its  subtype  is  word-aligned. 
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F.4.6  Task  Typas 


StocA^u  tor  «  task  activation 

As  described  in  the  LRM  [13.2],  you  can  use  the  length  clause  of  a 
size  specification  to  indicate  the  amount  of  storage  space  to  be 
reserved  for  the  activation  of  every  task  of  a  given  type. 

If  you  do  not  specify  storage  space  in  a  length  clause,  the  amount  of 
storage  apace  you  indicate  at  bind  time  is  allocated. 

You  cannot  use  a  length  clause  with  a  derived  type.  VS  Ada  reserves 
the  same  amount  of  storage  space  for  the  activation  of  a  task  of  a 
derived  type  as  for  the  activation  of  a  task  of  the  parent  type. 

Encoding  of  task  values 

Task  values  are  machine  addresses. 

Minimum  size  of  a  task  subtype 

The  minimum  size  of  a  task  subtype  is  32  bits. 

5ize  of  a  task  subtype 

The  size  of  a  task  subtype  is  32  bits,  the  same  as  its  minimum  size. 

The  only  size  you  can  specify  for  a  task  type  in  a  size  specification 
is  its  usual  size  (32  bits). 

Size  of  the  objects  of  a  task  subtype 

ka  object  of  a  task  subtype  is  the  same  size  as  its  subtype.  Thus,  an 
object  of  a  task  subtype  is  always  32  bits. 

Alignamnt  of  a  task  subtype 

A  task  subtype  is  always  word-aligned. 

Address  of  an  object  of  a  task  subtype 

Provided  its  alignment  is  not  constrained  by  a  record  representation 
clause,  the  address  of  an  object  of  a  task  subtype  is  always  on  a  word 
boundary  since  its  subtype  is  word-aligned. 
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F.4.7  Array  Types 


Lat/out  of  an  array 

Every  array  is  allocaced  in  a  contiguous  area  of  storage  units.  Ail 
the  components  of  an  array  are  the  same  size.  A  gap  may  exist  between 
two  consecutive  components  and  after  the  last  component.  All  gaps  are 
the  same  size. 

Components 

If  the  array  is  not  packed,  its  components  are  the  same  size  as  the 
subtype  of  the  components. 

For  example: 

type  A  is  array  (1  ..  3)  of  BOOLEAN; 

--  The  size  of  the  components  of  A  is  the  size  of  the 
--  type  BOOLEAN:  9  bits. 

type  DECIMAL_DIGIT  is  range  0  ..  9; 
for  DECIMAL_DIG1T' SIZE  use  4; 
type  BINARY_CODED_DECIMAL  is 

array  (INTEGER  range  <>)  of  DECIMAL_DIGIT; 

--  The  size  of  the  type  DECIMAL_DIGIT  is  4  bits.  Thus,  in  an  array 
--  of  type  BINARY_CODED_DECIMAL,  each  component  will  be  represented 
--  in  4  bits  as  in  the  usual  BCD  representation. 

If  the  array  is  packed  and  its  components  are  neither  records  nor 
arrays,  the  size  of  the  components  is  the  minimum  size  of  the  subtype 
of  the  components. 

For  example: 

type  A  is  array  (1  ..  3)  of  BOOLEAN; 
pragma  PACK( A) ; 

—  The  size  of  the  components  of  A  is  the  minimum  size  of  the  type 
--  BOOLEAN;  1  bit. 

type  DECIMAL_DIGIT  is  range  0  ..  9; 
type  BINARY_CODED_DECI.MAL  is 

array  (INTEGER  range  <>)  of  DECIMAL_DIGIT; 
pragma  PACK(  BINARY_CODED_DECI.MAL)  ; 

--  The  size  of  the”type  DECIMAL_DIGIT  is  16  bits;  but  as 
--  BINARY  CODED  DECIMAL  is  packed,  each  component  of  an  array  of  this 
--  type  will  be  represented  in  4  bits  as  in  the  usual  BCD 
--  representation. 

Packing  the  array  has  no  effect  on  the  size  of  its  components  when  the 
components  are  records  or  arrays. 
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G*ps 

Provldad  an  array  is  not  packad,  its  componants  ara  racords  or  arrays, 
and  no  sisa  spacification  appXiaa  to  tha  subtypa  of  tha  components, 
tha  compiler  may  choosa  a  raprasantation  vith  a  gap  aftar  aach 
componant.  By  insarting  such  gaps,  tha  compilar  optimizes  access  to 
the  array  components  and  thair  subcomponents.  The  size  of  the  gaps  is 
such  that  tha  relative  displacement  of  consecutive  components  is  a 
multiple  of  the  alignment  of  tha  subtypa  of  tha  components.  This 
strategy  gives  each  component  and  subcomponent  an  address  consistent 
with  tha  alignment  of  its  subtypa 

For  example: 

type  R  is 

record 

K  :  INTEGER;  --  INTEGER  is  word  aligned. 

B  :  BOOLEAN;  —  BOOLEAN  is  byte  aligned, 
end  record: 

—  Record  type  R  is  word-aligned.  Its  size  is  40  bits, 
type  A  is  array  (I  ..  10)  of  R; 

—  A  gap  of  three  bytes  is  inserted  after  each  component  in  order  to 

—  respect  the  alignment  of  type  R.  The  size  of  an  array  of  type  A 

—  will  be  640  bits. 

If  the  array  is  packed,  or  if  a  size  specification  does  apply  to  the 
subtype  of  the  components,  no  gaps  are  inserted. 

For  example: 

type  R  is 

record 

K  :  INTEGER; 

B  :  BOOLEAN; 
end  record; 

type  A  is  array  (1  ..  10)  of  R; 
pragma  PACR(A); 

—  Thara  is  no  gap  in  an  array  of  type  A  because  A  is  packed. 

--  The  size  of  an  object  of  type  A  will  be  400  bits. 

type  NR  is  new  R; 
for  NH'SIZE  use  40; 

type  B  is  array  (1  ..  10)  of  NR; 

—  There  is  no  gap  in  an  array  of  type  B  because  NR  has  a 

—  size  spacification. 

--  Tha  size  of  an  object  of  typo  B  will  bo  400  bits. 
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Sire  of  an  array  subtype 

The  size  of  an  array  subtype  is  obtained  by  multiplying  the  number  of 
its  components  by  the  sum  of  the  size  of  the  components  and  the  size 
of  any  gaps.  If  the  subtype  is  unconstrained,  the  maximum  number  of 
components  is  used  to  determine  the  size. 

The  size  of  an  array  subtype  cannot  be  computed  at  compile  time  in  the 
following  cases; 

•  If  the  array  subtype  has  nonstatic  constraints  or  if  it  is  an 
unconstrained  array  type  with  nonstatic  index  subtypes  (because 
the  number  of  components  can  then  only  be  determined  at  run  time). 

•  If  the  components  are  records  or  arrays  and  their  constraints  or 
the  constraints  of  their  subcomponents  (if  any)  are  not  static 
(because  the  size  of  the  components  and  the  size  of  the  gaps  can 
then  only  be  determined  at  run  time). 

\s  indicated  previously,  the  effect  of  a  pragma  PACK  on  an  array  type 
is  to  suppress  the  gaps  and  reduce  the  size  of  the  components.  Thus, 
packing  an  array  type  reduces  itr  size. 

If  the  components  of  an  array  are  records  or  arrays  and  their 
constraints  or  the  constraints  of  any  subcomponents  are  not  static, 
the  compiler  ignores  any  pragma  PACK  applied  to  the  array  type  but 
issues  a  warning  message.  Apart  from  this  limitation,  array  packing 
is  !ully  implemented  oy  the  VS  Ada  compiler. 

The  only  size  you  can  specify  for  an  array  type  or  first-named  suotype 
in  the  length  clause  of  a  size  specification  is  its  usual  size. 
Nevertheless,  a  length  clause  can  be  useful  to  verify  that  the  layout 
of  an  array  is  the  layout  expected  by  the  application. 

Size  of  the  objects  of  an  array  subtype 

An  object  of  an  array  subtype  is  always  the  same  size  as  the  subtype 
of  the  object. 

Alignment  of  an  array  subtype 

If  no  pragma  PACK  applies  to  an  array  subtype  and  no  size 
specification  applies  to  its  components,  the  array  subtype  has  the 
same  alignment  as  the  subtype  of  its  components. 

If  a  pragma  PACK  does  apply  to  an  array  subtype  or  if  a  size 
specification  applies  to  its  components  (so  that  there  are  no  gaps), 
the  alignment  of  the  array  subtype  is  the  lesser  of  the  alignment  of 
the  subtype  of  its  components  and  the  relative  displacement  of  the 
components . 
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KddrtJhs  of  an  objmct  of  an  array  subtype 

Providad  its  alignment  is  not  constrained  by  a  record  representation 
clause,  the  address  at  an  object  of  an  array  subtype  is  a  multiple  of 
the  alignment  of  the  corresponding  subtype. 


F.4.8  Record  Types 

Layout  of  a  record 

Every  record  is  allocated  in  a  contiguous  area  of  storage  units.  The 
size  of  a  record  component  depends  on  its  type.  Gaps  may  exiist 
between  some  components. 

As  described  in  the  LRM  [13.4],  you  can  use  a  record  representation 
clause  tu  control  the  positions  and  sizes  of  a  record's  components. 

VS  Ada  imposes  no  restrictions  on  a  component's  position.  Bits  within 
a  storage  unit  are  numbered  from  0  to  7,  with  the  most-significant  bit 
numbered  0.  The  range  of  bits  specified  in  a  component  clause  may 
extend  into  following  storage  units.  If  a  component  is  not  a  record 
or  an  array,  its  size  can  be  any  size  from  the  minimum  size  to  the 
size  of  its  subtype.  If  a  component  is  a  record  or  an  array,  its  size 
must  be  the  size  of  its  subtype: 

type  CONDITIONS  is  (ZERO,  LESS^THAH,  GREATER_THAN,  OVERFLOW); 

--  The  size  of  CONDITIONS  is  8  bits;  the  minimum  size  is  2  bits 

type  PR0G_EXCEPTI0N  is  (FIX^OVFL,  DEC_OVFL,  EXP^UNDFL,  SIGNIF); 
type  PROG~MASK  is  array  ( PROG_EXCEPTION)  of  BOOLEAN; 
pragma  PACK  (PR0G_MASK); 

--  The  size  of  PROG_MASK  is  4  bits 

type  ADDRESS  is  range  0..2**24-I; 
for  ADDRESS 'SIZE  use  24; 

—  ADDRESS  represents  a  24-bit  memory  address 

type  INTERRUPT  is  (10,  CLOCK,  MACHINE_CHECK) ; 

type  INTERRUPT_MASK_TYPE  is  array  (INTERRUPT)  of  BOOLEAN; 

type  INTERRUPT_CODE  is  range  0  ..  7; 

type  PR0C_LEVEL  is  range  0  ..  7; 
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typ*  PROORAM_COMTROL_I»OW)  Is 
Eseosd 

IIII*llRUPT_CAOSB 
CTlU«*rr_IHST_ADDRESS 
fUaT.STATX 
COHTROZiJMODC 
PR0TBCT10H_TRAP 
V1RTUXL_MACH1HB 
I!ITERRUPT_><ASK 
DBBUO_COMTROL 
C0ND1TI0H_C0DK 
PROGRAM_MASK 
PROCESS_LBVEL 
«nd  racord; 


INTBRROPT_CODB ; 
ADDRBSS; 

BOOLEAN; 

BOOLEAN; 

BOOLEAN: 

BOOLEAN; 

INTBBRUPT_N»iSK_TrPf  ; 
BOOLEAN; 

CONDITIONS; 

PROG_MASR; 

PROC_LEVBL; 


—  This  typa  can  ba  used  to  map  the  progran  control  word  of  the  VS. 


for  PROGRAM_CONTROL_WORD  uaa 
record  at  mod  4; 


INTBRRaPT_CAUSB 

at 

0 

range 

0 

7; 

CURRENT_TNST_ADD RE S S 

at 

1 

range 

8 

31; 

WAIT_STATE 

at 

4 

range 

0 

0; 

CONTROL_MODE 

at 

4 

range 

1 

1; 

PR0TECT10N_TRAP 

at 

4 

range 

2 

2; 

VIRTUAL_MACHINE 

at 

4 

range 

3 

3; 

INTERRUPT_MASK 

at 

4 

range 

5 

7;—  bit  4  unused 

DEBUG.CONTROL 

at 

5 

range 

0 

0;—  bits  1..7  unused 

CONDITION.CODE 

at 

6 

range 

0 

l; 

PROGRAM.MASK 

at 

6 

range 

2 

5;—  bits  6,7  unused 

PRCXESS.LEVBL 

at 

7 

range 

5 

7;—  bite  0..4  unused 

and  record; 


You  need  not  specify  the  size  and  position  of  every  component  of  a 
record  in  a  record  representation  clause.  If  you  do  not  specify  size, 
the  component  is  the  sane  size  as  its  subtype.  If  you  do  not  specify 
position,  the  compiler  chooses  the  position  that  optimizes  access  to 
the  components  of  the  record:  the  offset  of  the  component  is  a 
multiple  of  the  alignment  of  the  component  subtype.  The  compiler  also 
chooses  a  position  that  reduces  the  number  of  gaps  and  thus  the  size 
of  the  record  objects. 


Because  of  these  optimizations,  there  is  no  connection  between  the 
order  of  components  in  a  record  type  declaration  and  the  positions  of 
the  components  in  a  record  object. 


Pragma  PACK  has  no  further  effect  on  records.  The  compiler  always 
optimizes  the  layout  of  records  as  described  above. 
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Indirmct  eomponmnts 

If  thm  offset  of  s  compoaonc  caaaot  bo  computed  at  compile  time,  the 
offset  is  stored  in  the  record  objects  at  run  time  and  used  to  access 
the  component.  Such  a  component  is  said  to  be  indirmct s  other 
components  are  said  to  be  direct. 

If  a  record  component  is  a  record  or  an  array,  the  sise  of  its  subtype 
may  be  evaluated  at  run  time  and  may  even  depend  on  the  discriminants 
of  the  record.  w«  will  call  these  components  dynmmic  components. 

For  example: 

type  DEVICE  is  (SCREEN,  PRINTER); 
type  COLOR  is  (GREEN,  RED,  BLUE); 

type  SERIES  is  array  (POSITIVE  range  <>)  of  INTEGER; 

type  GRAPH  (L  :  NATURAL)  is 
record 

X  :  SERIESd  ..  L);  —  The  sise  of  X  depends  on  L 

Y  :  SERIESd  ..  L);  —  The  sise  of  Y  depends  on  L 

end  record; 

Q  :  POSITIVE; 

type  PICTURE  (N  :  NATURAL;  D  :  DEVICE)  is 
record 

F  :  GRAPH(H);  --  The  sise  of  F  depends  on  N 

S  :  GRAPH(Q);  —  The  sise  of  S  depends  on  Q 

case  0  is 

when  SCREEN  «> 

C  :  COLOR; 
when  PRINTER  «> 
null; 

end  case;  '  ^ 

end  record; 

Any  component  placed  after  a  dynamic  component  has  an  offset  that 
cannot  be  evaluated  at  compile  time  and  is  thus  indirect.  In  order  to 
minimise  the  number  of  indirect  components,  the  compiler  groups  the 
dynamic  components  together  and  places  them  at  the  end  of  the  record. 

Thus,  the  only  indirect  components  are  dynamic  coaiponents.  But  not 
all  dynamic  components  are  necessarily  indirect:  If  a  component  list 
that  is  not  followed  by  a  variant  part  contains  dynamic  components, 
exactly  one  dynamic  component  of  this  list  is  a  direct  component 
because  its  offset  can  be  computed  at  compilation  time. 
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The  offset  of  an  indirect  component  is  always  expressed  in  storage 
units. 

The  space  reserved  for  the  offset  of  an  indirect  component  must  be 
large  enough  to  store  the  size  of  any  value  of  the  record  typo  (the 
maximum  potential  offset).  The  compiler  evaluates  an  upper  bound  MS 
of  this  size  and  treats  an  offset  as  a  component  having  an  anonymous 
integer  type  whose  range  is  0  . .  MS. 

If  C  is  the  name  of  an  indirect  component,  then  the  offset  of  this 
component  can  be  denoted  in  a  component  clause  by  the 
implementation-generated  name  C* OFFSET. 

Implicit  components 

In  some  circumstances,  access  to  an  object  of  a  record  type  or  to  its 
components  involves  computing  information  that  depends  only  on  the 
discriminant  values.  To  avoid  unnecessary  recomputation,  the  compiler 
stores  this  information  in  the  record  objects,  updates  it  when  the 
values  of  the  discriminants  are  modified,  and  uses  it  when  the  objects 
or  their  components  are  accessed.  This  information  is  stored  in 
special  components  called  implicit  components. 

An  implicit  component  may  contain  information  that  is  used  when  the 
record  object  or  several  of  its  components  are  accessed.  In  this 
case,  the  component  is  included  in  any  record  object;  that  is,  the 
implicit  component  is  considered  to  be  declared  before  any  variant 
part  in  the  record  type  declaration.  There  are  two  components  of  this 
kind:  REC0RD_SI2E  and  VARIANT_INDEX. 

On  the  other  hand,  an  implicit  component  may  be  used  to  access  a  given 
record  component.  In  this  case  the  implicit  component  exists  whenever 
the  record  component  exists;  that  is,  the  implicit  component  is 
considered  to  be  declared  at  the  same  place  as  the  record  component. 
There  are  two  components  of  this  kind:  ARRAY_DESCRIPTORS  and 
RECORD_DESCRIPTORS . 

The  1  plicit  components  RECORD_SIZE,  VARIA11T_INDEX,  ARRAV_DESCRIPTORS , 
and  RECORO_OESCRIPTORS  are  described  as  follows: 

SECOSD_SIZE  -  The  compiler  creates  the  implicit  component 
RECORO_SIZE  when  the  record  type  has  a  variant  part  and  its 
discriminants  are  defaulted.  RECORO_SIZE  contains  the  size  of  the 
storage  space  needed  to  store  the  current  value  of  the  record 
object.  (Note  that  the  storage  actually  allocated  for  the  record 
object  may  be  larger.) 

The  value  of  a  RECORO_SIZ£  component  may  denote  a  number  of  storage 
units  or  a  number  of  bits.  Generally  it  denotes  a  number  of  storage 
units,  but  if  any  component  clause  specifies  that  a  component  of  the 
record  type  has  an  offset  or  a  size  that  cannot  be  expressed  using 
storage  units,  then  the  value  denotes  a  number  of  bits. 
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Th«  implicit  component  R£CORD_SIZE  must  be  large  enough  to  store  the 
maximuin  size  of  any  value  of  the  record  type.  The  compiler 
evaluates  an  upper  bound  MS  of  this  size  and  then  considers  the 
implicit  component  to  have  an  anonymous  integer  type  whose  range  is 
0  . .  MS. 

If  R  is  the  name  of  the  record  type,  the  implicit  component 
RCCORO^SIZE  can  be  denoted  in  a  component  clause  by  the 
implementation>generated  name  R‘RECORD_SIZE. 

7ABXAllT_IttOEX  —  The  compiler  creates  the  implicit  component 
VARIANT^INOEX  when  the  record  type  has  a  variant  part. 

VARIAMT^INDEX  indicates  the  set  of  components  that  are  present  in  a 
record  value.  It  is  used  when  a  discriminant  check  is  to  be  done. 

Component  lists  that  do  not  contain  a  variant  part  are  numbered. 
These  numbers  are  the  possible  values  of  the  implicit  component 
VARIANT_INDEX. 

For  example: 

type  VEHICLE  is  (AIRCRAFT,  ROCKET,  BOAT,  CAR); 

type  DESCRIPTION  (KIND  :  VEHICLE  ;=  CAR)  is 
record 

SPEED  i  INTEGER; 
case  KIND  is 

when  AIRCRAFT  |  CAR  *> 

WHEELS  :  INTEGER; 
case  KIND  is 

when  AIRCRAFT  «>  —  1 

WINGSPAN  :  INTEGER; 
when  others  «>  —  2 

null; 

end  case; 

when  BOAT  »>  —  3 

STEAM  :  BOOLEAN; 
when  ROCKET  «>  --4 

STAGES  :  INTEGER; 

end  case; 
end  record; 
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Th«  value  of  the  variant  index  indicates  the  set  of  components  that 
are  present  in  a  record  value: 


Variant  Index 

Set 

1 

{KIND, 

SPEED, 

WHEELS,  WINGSPAN} 

2 

{KIND. 

SPEED. 

WHEELS) 

3 

{KIND. 

SPEED, 

STEAM} 

4 

{KIND, 

SPEED, 

STAGES} 

A  comparison  between  the  variant  index  of  a  record  value  and  the 
bounds  of  an  interval  serves  to  check  that  a  igiven  component  is 
present  in  the  value: 


Component 

Interval 

KIND 

.. 

SPEED 

— 

WHEELS 

1  .  .  2 

WINGSPAN 

1  .  .  1 

STEAM 

3  ..  3 

STAGES 

4  .  .  4 

The  implicit  component  yARIAKT_INDEX  must  be  large  enough  to  store  the 
number  V  of  component  lists  that  do  not  contain  variant  parts.  The 
compiler  treats  this  implicit  component  as  having  an  anonymous  integer 
type  whose  range  is  1  ..  V. 

If  R  is  the  name  of  the  record  type.  VARIANT_Ibn)EX  can  be  specified  in 
a  component  clause  by  the  implementation-generated  name 
R’VARIANT_INDEX. 

AKKAT_DBSCBIPTOB  --  The  compiler  associates  the  implicit  component 
ARRAy'dESCRIPTOR  with  each  record  compo.ient  whose  subtype  is  an 
anonymous  array  subtype  that  depends  on  a  discriminant  of  the  record. 
ARFAY_DESCRIPTOR  contains  information  about  the  component  subtype. 

The  structure  of  the  i.mplicit  component  ARRAY_DESCRIPTOR  is  not 
described  in  this  documentation.  However,  if  you  wish  to  specify  the 
location  of  an  ARRAY_DESCRIPTOR  component  in  a  component  clause,  you 
can  obtain  the  size  of  the  component  by  specifying  DMAP  *  YES  when  you 
run  the  compiler. 
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Th«  compiler  treats  an  Xllltxy__DCSCHXPTOR  implicit  compeuent  as  having 
an  anonymous  record  type.  If  C  is  the  name  of  the  record  component 
whose  subtype  is  described  by  the  array  descriptor,  then 
AltBAY_DCSCSZPTOR  can  be  specified  in  a  component  clause  by  the 
implementation-generated  name  C'AIRAy^DESCRZPTOR. 

R1C0RD_DBSCR1PT0R  --  The  compiler  associates  the  implicit  component 
RECORD^OESCRZPTOR  with  each  record  component  whose  subtype  is  an 
anonymous  record  subtype  that  depends  on  a  discriminant  of  the 
record.  RECORO^DESCRIPTOR  contains  information  about  the  component 
subtype. 

The  structure  of  the  implicit  component  RCCORD_OESCRZPTOR  is  not 
described  in  this  documentation.  However,  if  you  wish  to  specify  the 
location  of  a  RECORD_OESCRIPTOR  component  in  a  component  clause,  you 
can  obtain  the  size  of  the  component  by  specifying  DMAP  *  YES  when 
you  run  the  compiler. 

The  compiler  treats  a  RCCORO_D£SCRIPTOR  implicit  component  as  having 
an  anonymous  record  type.  If  C  is  the  name  of  the  record  component 
whose  subtype  is  described  by  the  record  descriptor,  then 
REC0R0_DESCB1PT0R  can  be  specified  in  a  component  clause  by  the 
implementation-generated  name  C'RECORD^DSSCRIPTOR. 

Suppressing  implicit  components 

The  VS  Ada-defined  pragma  IMPROVE  enables  you  to  suppress  the  implicit 
components  RECORO^SIZE  and/or  VARZAHT.INDEX  from  a  record  type.  The 
syntax  of  pragma  IMPROVE  is  as  follows: 

pragma  IMPROVE  (  TIME  |  SPACE  ,  [OH  «>]  simple_name  ); 

The  first  argument  specifies  whether  TIME  or  SPACE  is  the  primary 
criterion  for  the  choice  of  the  representation  of  the  record  type, 
which  is  denoted  by  the  second  argument. 

If  you  specify  TIME,  the  compiler  inserts  implicit  components  as 
described  above.  If  you  specify  SPACE,  the  compiler  inserts  a 
VARIAHT^INDEX  or  a  RECORD_SIZE  component  only  if  that  component 
appears  in  a  record  representation  clause  that  applies  to  the  record 
type.  Thus,  you  can  use  a  record  representation  clause  to  keep  one 
implicit  component  while  suppressing  the  other. 

A  pragma  IMPROVE  that  applies  to  a  given  record  type  can  occur 
anywhere  a  representation  clause  is  allowed  for  that  type. 

Size  of  a  record  subtype 

Unless  a  component  clause  specifies  that  a  component  of  a  record  type 
has  an  offset  or  a  size  which  cannot  be  expressed  using  storage  units, 
the  sise  of  a  record  subtype  is  rounded  up  to  a  whole  number  of 
storage  units. 
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Th«  S.'S*  oC  a  constrained  record  subtype  is  obtained  by  adding  the 
sizes  of  its  components  and  the  sizes  of  any  gaps.  The  size  is  not 
computed  at  compile  time  if  the  record  subtype  has  nonstatic 
constraints  or  if  a  component  is  an  array  or  a  record  and  its  size  is 
not  computed  at  compile  time. 

The  size  of  an  unconstrained  record  subtype  is  obtained  by  adding  the 
sizes  of  the  components  and  the  sizes  of  any  gaps  of  its  largest 
variant.  If  the  size  of  a  component  or  gap  cannot  be  evaluated 
exactly  at  compile  time,  the  compilsr  uses  an  upper  bound  of  this  size 
to  compute  the  subtype  size. 

k  size  specification  applied  to  a  record  type  or  first-named  subtype 
has  no  effect:  The  only  size  you  can  specify  is  the  default  size  of 
the  record  type  or  first-named  subtype.  Mevertheless .  a  length  clause 
can  be  useful  to  verify  that  the  layout  of  a  record  is  the  layout 
expected  by  the  application. 

Size  of  the  objects  of  a  record  subtype 

An  object  of  a  constrained  record  subtype  is  the  same  size  as  its 
subtype. 

An  object  of  an  unconstrained  record  subtype  is  the  same  size  as  its 
subtype  if  that  size  is  less  than  or  equal  to  8  Kbyte.  If  the  size  of 
the  subtype  is  greater  than  8  Kbyte,  the  object  is  the  size  that  is 
necessary  to  store  its  current  value.  Storage  space  is  allocated  and 
released  as  the  discriminants  of  the  record  change. 

Alignment  of  a  record  subtype 

When  no  record  representation  clause  applies  to  its  base  type,  a 
record  subtype  has  the  same  alignment  as  the  component  with  the 
highest  alignment  requirement. 

When  a  record  representation  clause  that  does  not  contain  an  alignment 
clause  applies  to  its  base  type,  a  record  subtype  has  the  same 
alignment  as  the  component  with  the  highest  alignment  requirement  that 
has  not  been  overridden  by  its  component  clause. 

When  a  record  representation  clause  that  contains  an  alignment  clause 
applies  to  its  base  type,  a  record  subtype  has  the  alignment  specified 
by  the  alignment  clause. 

Address  of  an  object  of  a  record  subtype 

Provided  its  alignment  is  not  constrained  by  a  representation  clause, 
the  address  of  an  object  of  a  record  subtype  is  a  multiple  of  the 
alignment  of  the  corresponding  subtype. 
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F.S  Convtntiont  for  Implomontatlon-Gonoratod  Namos 


Th«  conpilar  introduces  special  record  components  for  certain  record 
type  definitions-.  Such  record  components  are 

implementation>dependent;  they  are  used  by  the  compiler  to  improve  the 
quality  of  the  generated  code  for  certain  operations  on  the  record 
types. 

The  compiler  issues  an  error  message  if  you  refer  to  an 
implementation-dependent  component  that  does  not  exist.  If  the 
implementation-dependent  component  does  exist*  the  compiler  checks 
that  the  storage  location  specified  in  the  component  clause  is 
compatible  with  the  treatment  of  the  component  and  the  storage 
locations  of  other  components,  issuing  an  error  message  if  this  check 
fails. 

Four  attributes  are  defined  to  refer  to  these  implementation-dependent 
components  in  record  representation  clauses: 

T‘BECOBO_SIZK  —  For  a  prefix  T  that  denotes  a  record  type.  This 
attribute  refers  to  the  record  component  introduced  by  the  compiler 
in  a  record  to  store  the  sise  of  the  record  object.  This  component 
exists  for  objects  of  a  record  type  with  defaulted  discriminants 
when  the  sixes  of  the  record  objects  depend  on  the  values  of  the 
discriminants . 

T'VABIAirT_IHDKX  --  For  a  prefix  T  that  denotes  a  record  type.  This 
attribute  refers  to  the  record  component  introduced  by  the  compiler 
in  a  record  to  assist  in  the  efficient  implementation  of 
discriminant  checks.  This  component  exists  for  objects  of  a  record 
type  with  variant  type. 

C'AS£AX_OB8CSXPTOB  —  For  a  prefix  C  that  denotes  a  record  component 
of  an  array  type  whose  component  subtype  definition  depends  on 
discriminants.  This  attribute  refers  to  the  record  component 
introduced  by  the  compiler  in  a  record  to  store  information  on 
subtypes  of  components  that  depend  on  discriminants. 

C*BBCOBD_DBSCBIPTOB  —  For  a  prefix  C  that  denotes  a  record 
component  of  a  record  type  whose  component  subtype  definition 
depends  on  discriminants.  This  attribute  refers  to  the  record 
component  introduced  by  the  compiler  in  a  record  to  store 
information  on  subtypes  of  components  that  depend  on  discriminants. 
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ADDRESS  CLAUSES 


F.6 

F.6.1  Addr«ss  Clausas  for  Objacts 

As  dtscribed  in  th*  LHM  [13. S],  you  can  us*  an  address  clause  Co 
specify  an  address  for  an  object.  When  you  do  us*  an  address  clause, 
no  storage  is  allocated  for  the  object  in  the  program  generated  by  the 
compiler.  Instead,  the  program  uses  the  address  specified  in  the 
clause  to  access  the  object. 

You  cannot  use  an  address  clause  for  task  objects  or  for  unconstrained 
records  whose  maximum  possible  size  is  greater  than  8  Kbytes. 

F.6.2  Address  Clauses  for  Program  Units 

Address  clauses  for  program  units  are  not  implemented  in  t.he  current 
version  of  VS  Ada. 


F.6.3  Address  Clauses  for  Entries 

Address  clauses  for  entries  are  not  implemented  in  the  current  version 
of  VS  Ada. 


F.7  Restrictions  on  Unchecked  Conversions 

Unconstrained  arrays  are  not  allowed  as  target  types,  nor  are 
unconstrained  record  types  without  defaulted  discriminants  allowed  as 
target  types. 

If  the  source  and  the  target  types  are  each  scalar  or  access  types, 
the  sizes  of  the  objects  of  the  source  and  target  types  must  be 
equal.  If  a  composite  type  is  used  either  as  the  source  type  or  as 
the  target  type,  this  size  restriction  does  not  apply. 

If  the  source  and  the  target  types  are  each  of  scalar  or  acces.s  type 
or  if  they  are  both  of  composite  type,  the  function  returns  the 
operand. 

In  other  cases  the  effect  of  unchecked  conversion  can  be  considered  a 
copy; 

•  If  an  unchecked  conversion  of  a  scalar  or  access  source  type  to  a 
composite  target  type  is  achieved,  the  result  of  the  function  is  a 
copy  of  the  source  operand;  the  result  is  the  size  of  the  source. 

•  If  an  unchecked  conversion  of  a  composite  source  type  to  a  scalar 
or  access  target  type  is  achieved,  the  result  of  the  function  is  a 
copy  of  the  source  operand;  the  result  is  the  size  of  the  target. 
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F.8 


IMPLEM6NTATI0N-0€PEN0ENT  CHARACTERISTICS  OF  THE 
INPUT<OUTPUT  PACKAGES 


The  package  L.OW_^LEVEL_IO  [14.6],  which  is  conearnad  with 
machina-dapandant  input-output,  is  not  implamantad  in  VS 
pradafinad  input-output  packagaa  SEQUENTZAL^IO  [14.2.3], 
[14.2.5],  TErr_IO  [14.3.10]  and  IO_EXCEPTIONS  [14.5]  ara 
as  described  in  the  Language  Rafaranca  Manual. 


low-laval 
Ada .  The 
DIRECT_IO 
ifflplamantad 


This  section  describes  those  characteristics  of  the  input-out  packages 
that  are  specific  to  Wang  VS  Ada. 


F.8.1  Unbounded  Line  Lengths 

vs  Ada  does  not  support  unbounded  line  lengths. 

F.8.2  The  FORM  Parameter 

The  FORM  parauneter  is  passed  to  the  Ada  CREATE  and  OPEN  procedures  to 
specify  VS  file  attributes. 

FORM  is  an  optional  parameter.  If  you  omit  it  or  pass  it  as  a  null 
string,  the  file  assumes  VS  default  attributes.  If  you  do  include  the 
FORM  parameter  when  creating  or  opening  a  file,  you  need  not  specify  a 
value  for  every  attribute.  In  some  cases,  the  attribute  may  not  apply 
(o.g.,  a  disk  file  cannot  take  a  tape  label  type).  In  other  cases, 
you  may  choose  to  accept  the  default  value  for  the  attribute. 

The  syntax  of  the  FORM  string  is: 

form_parameter  ::s  [  attribute  [  {,  attribute^  ]  ] 

attribute  key_^word  [  »>  value  ] 

Incorrect  syntax  causes  a  US£_ERROR  exception  to  bo  raised. 

The  following  section  contains  a  description  of  each  attribute 
supported  by  the  FORM  parameter. 
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AttributM  of  tho  FORM  Paramotor 

This  ssction  lists  and  dsscribss  th*  VS  tfil*  attributas  supported  by 
the  FORM  parameter.  The  attributes  are  listed  alphabetically,  and 
each  entry  includes  the  following  information: 

•  Description  -  ^  brief  description  of  what  the  attribute  does 

•  Values  -  A  list  of  the  possible  values  for  the  attribute,  followed 
by  explanations  where  necessary 

•  Default  -  The  default  value  for  the  attribute 

•  Restrictions  -  Where  applicable,  a  description  of  any  restrictions 
that  apply  to  the  attribute 

The  VS  Data  Management  System  Reference  contains  detailed  information 
about  these  attributes. 


\PPEND 


Description: 


Values : 


Default: 
Restrictions : 


BLOCK_SIZE 

Description: 

Values : 
Default: 


BUF^SIZE 

Description: 

Values : 

Default: 
Restrictions : 


The  APPEND  attribute  specifies  whether  output  is 
appended  to  the  file  or  overwrites  the  existing 
file. 

APPEND  «>  [YES  I  NO] 

If  APPEND  a>  YES.  the  record  pointer  is  positioned 
at  end-of-file  and  output  is  appended  to  the  file. 

If  APPEND  >>  NO.  the  record  pointer  Is  positioned 
at  the  beginning  of  the  fils  and  output  overwrites 
the  existing  file. 

The  default  is  NO. 

Failure  to  meet  the  following  condition  causes  a 
USE^ERROR  to  be  raised: 

APPEND  YES  cm  be  used  only  on  existing  files 
opened  for  OUT_FILE  or  INOUT^FILE  mode. 


The  BLOCK_SIZE  attribute  specifies  the  size  in 
bytes  of  the  DMS  block  for  the  file. 

BLOCK^SIZE  =>  [2048  ...  32768] 

The  default  (and  only  legal  value)  for  DISK. 
PRINTER,  and  WS  devices  is  2048. 

The  default  for  TAPE  devices  is  2048. 


The  BUF_SIZE  attribute  specifies  the  size  in  bytes 
of  the  DMS  buffer  for  the  file. 

BUF  SIZE  =>  [2048  |  4096  |  6144  |  8192  |  10240  | 
12288  I  14336  |  16384  |  18432] 

The  default  is  2048. 

Failure  to  meet  the  following  condition  causes  a 
USE^ERROR  to  be  raised: 

BUF^SIZE  must  be  a  multiple  of  2048  bytes  (2K),  in 
the  range  2048  (2K)  to  18412  (18K). 
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COMPRESS 


Description: 


Values : 


Default : 


The  COMPRESS  attribute  specifies  whether  or  not  DMS 
automatically  compresses  records. 

COMPRESS  «>  [YES  |  Mg] 

If  COMPRESS  s>  YES,  DMS  compresses  records. 

If  COMPRESS  =>  NO,  DMS  does  not  compress  records. 
The  default  is  NO. 


CONFIRM 


Description:  The  CONFIRM  attribute  specifies  whether  or  not  DMS 

automatically  scratches  a  file  when  you  cail  the 
CREATE  procedure  with  the  file  name  (NAME)  of  an 
existing  external  file. 

Values:  CONFIRM  =>  [YES  |  NO] 

If  CONFIRM  =>  YES,  DMS  issues  a  GETPARM  asking  you 
to  confirm  the  deletion  of  the  existing  file. 

If  CONFIRM  s>  NO,  DMS  automatically  deletes  the 
file. 

Default:  The  default  is  NO. 


DENSITY 


Description:  The  DENSITY  attribute  applies  to  tape  files  only 

(DEVICE  =>  TAPE).  It  specifies  the  density  of  a 
tape  in  bits  per  inch  (BPI). 

Values:  DENSITY  *>  [526  |  800  |  1600  |  6250] 


Default:  The  default  is  1600. 
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DEVICE 


Daac; Iption: 

Valutts i 
D«f aul t i 
Kasti ictions ; 


DISMOUNT 

Da.scription: 

Values : 

Default : 


The  DEVICE  attribute  specifies  the  device  that  is 
to  be  associated  with  the  file.  The  device  caa  be 
a  disk,  a  magnetic  tape,  a  printer,  or  a 
workstation. 

DEVICE  .>  [DISK  I  TAPE  |  PRINTER  |  WS ) 

The  default  is  DISK. 

Failure  to  meet  any  of  the  following  conditions 
causes  a  USE_ERRQR  to  be  raised: 

tf  DEVICE  a>  WS,  then  the  file  organization  must 
consecutive  (ORGANIZATION  =>>  CONSCCtrr-XVE)  . 

If  DEVICE  =>  PRINTER,  then  the  file  organization 
must  be  print  (ORGANIZATION  »>  PRINT)  and  the  open 
access  mode  must  be  OUT__FILE. 

If  DEVICE  TAPE,  the  file  cannot  bo  opened  for 
DIRECT^IO,  as  DMS  allows  neither  random  access  to 
or  updating  of  tape  records. 

If  DEVICE  3>  TAPE,  an  existing  file  cannot  be 
opened  in  0U1'_FILE  mode,  as  DMS  does  not  allow 
updating  of  tape  records. 

If  DEVICE  3>  DISK,  the  block  size  must  be  2048 
(BLOCK  SIZE  3>  2048). 


The  DISMOUNT  attribute  applies  to  tape  files  only 
(DEVICE  »>  TAPE).  It  specifies  whether  or  not  DMS 
logically  dismounts  a  tape  volume  when  it  closes 
the  tape  file. 

DISMOUNT  =)  [YES  1  NO] 

If  DISMOUNT  =>  YES,  DMS  dismounts  the  tape. 

If  DISMOUNT  =>  NO,  DMS  does  not  dismount  the  tape. 
The  default  is  NO. 
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DISPLAY 


Description: 

Values : 

Default: 
EOF_STRIHG  »> 
Description: 


Values : 

Default : 
FILE_CLASS 

Description: 

Values : 

Default; 


The  DISPLAY  attribute  specifies  whether  or  not  a 
GETPARM  screen  is  displayed  at  the  workstation  at 
runtime.  You  can  respecify  file  attributes  on  the 
GETPARM  screen  before  opening  the  file. 

DISPLAY  .>  (YES  |  WO) 

If  DISPLAY  »>  YES,  a  GETPARM  screen  is  displayed. 

If  DISPLAY  a>  NO.  a  GETPARM  screen  is  not  displayed. 
The  default  is  NO. 


The  EOF_STRING  attribute  applies  to  workstation 
files  only  (DEVICE  a  WS).  It  specifies  an 
end-of-file  (eof)  string.  If  a  line  equal  to  the 
eof  string  is  typed  in,  subsequent  calls  to  the 
END^QF_FILE  function  return  TRUE;  subsequent 
attempts  to  read  from  the  workstation  raise  the  END 
ERROR  exception. 

EOF_STRING  =>  [/^  |  sequence^of^characters 1 

Mote:  se<juence_pf_chacACtecs  cannot  contain  commas 
or  spaces. 

The  default  is  /•. 


The  FILE_CLASS  attribute  applies  to  disk  files  only 
(DEVICE  =>  DISK).  It  specifies  the  fi  e's  VS  file 
protection  class. 

FILE_CLASS  =>  [A  ...  2,  $,  (blank)] 

For  information  on  VS  fils  protection  classes,  see 
the  VS  System  User’s  Introduction. 

The  default  is  derived  from  your  usage  constants. 

For  information  on  how  to  set  usage  constants,  see 
the  VS  System  Usee’s  Introduction. 
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FILE  SEQ 


Description!  The  FILE_SEQ  attribute  applies  to  tape  files  only 
(DEVICE  =>  TAPE).  It  specifies  the  file  sequence 
number  of  a  tape  file. 

Values:  FILE_SEQ  =>  [1  ...  9999) 

Default:  The  default  is  1. 

FORCE_EOR 

Description!  The  FORCE_EOR  attribute  applies  to  tape  files  only 
(DEVICE  a)  TAPE).  It  specifies  whether  or  not  DMS 
forces  an  end-of-reel  when  it  closes  a  tape  file 
that  spans  multiple  volumes. 

Values:  FORCE_EOR  =>  [YES  |  MO) 

If  FORCE_EOR  =>  YES,  DMS  forces  end-of-reel. 

If  FORCE_EOR  s>  MO,  DMS  does  not  force  end-of-reel. 

Default:  The  default  is  NO. 

LABEL 

Description:  The  LABEL  attribute  applies  to  tape  files  only 

(DEVICE  =)  TAPE).  It  specifies  the  label  type  for 
a  tape. 

Values:  LABEL  =>  [NONE  |  ANY  |  ANSI  |  IBM) 

If  LABEL  NONE,  the  tape  contains  no  labels,  or 
it  contains  labels  that  correspond  to  neither  the 
ANSI  nor  the  IBM  standards.  DMS  treats  such  as 
labels  as  if  they  were  the  first  data  block(5)  of 
the  file. 

If  LABEL  =>  ANY,  the  existing  label  on  the  tape  is 
used. 

If  LABEL  =>  ANSI,  the  tape  contains  ANSI -standard 
labels,  which  are  written  in  ASCII. 

If  LABEL  =>  IBM,  the  tape  contains  IBM-standard 
labels,  which  are  written  in  EBCDIC. 

Default:  The  default  is  ANSI. 
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NOT_SHAi{ED 

SHARED 

Description: 

Values : 


Default : 

N_RECS 

Description: 

Values : 
Default: 


The  NOT_SHARED/ SHARED  attribute  specifies  whether 
or  not  several  internal  files  within  a  single 
program  can  share  one  external  file. 

MOT_.SHARED 

SHARED  >>  (READERS  |  SIHGLE_WR1TER  |  AHY] 

When  NOT_SHARED.  the  external  file  cannot  be  shared. 

When  SHARED  >>  READERS,  several  internal  files  can 
read,  but  not  update,  the  same  external  file. 

When  SHARED  =>  SZNGLE_WRITER,  one  internal  file  can 
update  an  external  file  while  several  other 
internal  files  read  the  same  file. 

When  SHARED  =>  AH^,  several  internal  files  can  botn 
read  and  update  one  external  file  simultaneously. 

The  sharing  mode  is  taken  from  the  "brother"  files 
if  there  are  any.  In  the  absence  of  brother  files, 
if  DEVICE  =>  WS,  then  SHARED  *>  AJNY;  if 
MODE  =>  IN_FILE,  then  SHARED  =>  READERS;  otherwise, 
the  sharing  mode  is  HOT_,SHARED. 


The  N_RECS  attribute  applies  to  disk  files  only 
(DEVICE  =>  DISK).  It  specifies  your  estimate  of 
the  number  of  records  the  file  will  contain.  QMS 
uses  this  estimate  to  calculate  the  number  of  disk 
blocks  to  allocate  for  the  primary  extent. 

H_RECS  =>  (1  ...  16777215] 

The  default  is  500. 
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ORGANIZATION 


Dascription: 


Values : 


Default: 


Restrictions : 


The  ORGANIZATION  attribute  specifies  the  file 
organization  type.  For  further  information  about 
file  organization,  see  the  VS  Data  Management 
System  Reference. 

ORGANIZATION  s>  f CONSECUTIVE  |  PROGRAM  |  PRINT] 

I 

If  ORGANIZATION  >>  CONSECUTIVE,  the  file  is  a  data 
file  consisting  of  consecutively  written  records  - 
that  is,  records  stored  in  the  order  in  which  they 
are  created. 

If  ORGANIZATION  =>  PROGRAM,  the  file  is  a 
consecutive  file  of  1024-byce  records  in  VS  program 
format . 

If  ORGANIZATION  =>  PRINT,  the  file  is  a  consecutive 
file  containing  program  output  to  be  sent  to  a 
printer . 

The  default  is  CONSECUTIVE  when  DEVICE  »>  DISK, 
TAPE,  and  WS.  When  DEVICE  »>  PRINTER, 

ORGANIZATION  =>  PRINT. 

Failure  to  meet  any  of  the  following  conditions 
causes  a  USE_ERROR  to  be  raised: 

If  ORGANIZATION  s>  PROGRAM,  then  the  record  size 
must  be  1024  bytes  (REC_S1ZE  =>  1024);  the  record 
format  must  be  fixed  (REC_FORMAT  *>  F);  and  the 
file  must  be  opened  for  either  SEQUENTIAL_IO  or 
DIRECT_IO. 

If  ORGANIZATION  s>  PRINT,  then  the  record  format 
must  be  variable  ( REC_FOfU<lAT  s>  V),  the  records 
must  be  compressed  (COMPRESS  s>  YES),  and  the  file 
must  be  opened  for  TEXT_I0. 

If  ORGANIZATION  »>  PRINT,  then  output  must 
overwrite  the  existing  file  (APPEND  =>  NO);  since 
DMS  does  not  allow  print  Jiles  to  be  opened  in  I/O 
mode,  output  cannot  be  appended  to  a  print  file. 


2c*5rirtic5 
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Pia)_CHAR 

Description:  The  PAO^CHXR  attribute  specifies  how  records  are 

padded. 

Values:  PAD_CHAR  x>  [HUL  (  BLANK  | 

any_^displayable_A5CII_character  J 

If  PAO_CHAS  x>  NUL,  records  are  padded  with  nulls 
(hex  00) 

If  PAD_CV-VR  •  BLANK,  records  are  padded  with 
blanks  'J). 

If  PAD_CHAR  a>  aay_displayable_ASCII_character, 
records  are  padded  with  that  character. 

Default:  The  default  for  sequential  and  direct  files  is  NUL. 

The  default  for  text  files  is  BLANK. 

PARITY 

Description:  The  PARITY  attribute  applies  to  tape  files  only 

(DEVICE  s>  TAPE),  It  specifies  parity  for  a 
7-track  tape.  (You  need  not  specify  parity  for 
9-track  tapes.) 

Values:  PARITY  =>  [ODD  |  EVEN] 

Default:  The  default  is  ODD. 

PRINT_CLASS 

Description:  The  PRZNT^CLASS  attribute  applies  to  print  files 

only  (DEVICE  =  PRINTER).  It  specifies  the  file's 
print  class. 

Values;  PRINT_CLASS  =>  (A  ...  Z] 

For  information  about  print  classes,  see  the  VS 
System  User's  Introduction. 

Default:  The  default  is  extracted  from  your  usage  constants. 

For  information  on  how  to  set  usage  constants,  see 
the  VS  System  User's  Introduction. 
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PRINT^FORM 

Description:  The  PRINT_FORM  attribute  applies  to  print  files 

only  (DEVICE  >  PRINTER).  It  specifies  the  type  of 
paper  to  be  mounted  in  the  printer.  Printing  is 
then  inhibited  if  the  vrong  paper  is  mounted. 

For  further  information  about  form  numbers,  see  the 
VS  System  Operator'^  Guide. 

Values:  PRINT_FOR.M  *>  [0  ...  255] 

Default:  The  default  is  extracted  from  your  usage  constants. 

For  information  on  how  to  set  usage  constants,  see 
the  VS  System  User’s  Introduction. 

PR_NAME 

Description:  The  PR^NAME  attribute  specifies  a  parameter 

reference  name  (prname)  for  the  file.  The  prname 
is  used  by  OMS  for  GETPARM  and  PUTPARM  processing. 

Values:  PR^NAME  =>  [ l_to_6__character_str ing] 

Default:  The  default  is  a  blank  string. 

REC_FORMAT 

Description:  The  REC_FORMAT  attribute  specifies  whether  the  file 

contains  fixed-length  or  variable-length  records. 

Values:  REC_FORMAT  =>  [F  |  Vj 

IF  REC^FORMAT  =>  F.  the  file  contains  fixed-length 
records . 

If  REC_FORMAT  =>  V.  the  file  contains 
variable-length  records. 

Default:  The  default  for  sequential  and  direct  files  is  F. 

The  default  for  text  files  is  V. 
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nmcjsitM 


D«»erlptlon: 

valu«ii : 
Oafault : 


Restrictions : 


RELEASE 

Description: 

Values : 

Default : 


The  REC.SXSI  attribute  specifies  the  site  la  bytes 
of  the  file's  records,  rot  ▼ariabie  length 
records^  RBC_SXZI  spacifiea  the  largest  size  record 
that  can  be  written  to  the  file. 

REC.SIZB  •>  [1  ...  2048] 

The  default  for  constrained  eleswnt  types  is  the 
size  of  the  instantiated  eleeant  type. 

The  defaults  for  unconstrained  slea«nt  types  ate 

2048  for  fixed- length  records  (REC^rORMAT  >>  T)  ; 
2024  for  variable-length  records 
(REC_rORMAT  ->  V) . 

The  default  (and  only  legal  value)  for  prograa  files 
(OROAMXZATION  •»  PROGRAM)  is  1024. 

Failure  to  sieet  any  of  the  following  conditions 
causes  a  USE_ERROR  to  be  raised: 

If  the  record  fonnat  is  fixed  (REC_rORMAT  •>  T) , 
then  REC^SXZE  cannot  exceed  2048  bytes. 

If  the  record  fomat  is  variable  (REC^PORMAT  •>  v) , 
then  REC.SXZB  cannot  exceed  2024  bytes. 

The  record  size  of  files  with  constrained  types 
that  are  opened  for  SXQgEMTIAL.IO  or  DIRECT.ZO  must 
be  equal  to 

(SLEMEMT.TTrE'SXZE  -  1)  /  STSTZM.STORAGE.UNXT  +  1. 
(This  is  the  minimum  nusdser  of  bytes  needed  to 
represent  an  object  of  ELEMBMT.TYPE . ) 


The  RELEASE  attribute  applies  to  (lis)c  files  only 
(DEVICE  *>  DISK) .  It  specifies  whether  or  not  DMS 
returns  unused  primary  extent  blocks  to  the 
operating  system  when  the  file  is  closed. 

RELEASE  ->  (TES  I  SQ] 

If  RELEASE  ->  TES,  DMS  returns  unused  blocks. 

If  RELEASE  ~>  NO,  DMS  does  not  return  unused  bloc)cs . 
The  default  is  NO. 
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RSnMTZOM 


MseriptiOBi 


Valuaat 

OaCauItt 

REWIND 

OaacriptioBi 


Valuta: 


Oafault: 

TRACKS 

Oaacriptioa: 

Valuta: 

Dtfault: 

TRUNCATE 

Otacription: 


Valuta: 


Dafault: 


Tha  RETENTION  attributt  applita  to  diak  filta  onl^ 
(DEVICE  s>  DISK).  It  apaeifita  tha  numbar  of  daya 
bayond  tha  data  of  ita  ertatidn  that  a  fila  la 
ratainad. 

RETENTION  >>  [0  ...  999] 

Tha  dafault  ia  0  (which  aptcifiaa  that  tha  flits 'a 
tsplratlon  datt  is  tha  aama  aa  its  craation  data). 


Tha  REWIND  attributt  applita  to  tapt  filta  only 
(DEVICE  a>  TAPE).  It  apacifita  whathar  or  cot  OMS 
rtwinda  tht  tapt  voliuna  whtn  it  dost;  t  tapt 
flit. 

REWIND  a>  [YES  |  NO] 

If  REWIND  a>  YES.  DMS  rtwinda  tht  tapa. 

If  REWIND  a>  NO.  OMS  dots  not  rtwind  tht  tapt. 

Tht  dt fault  is  NO. 


"'t  TRACKS  attributt  applita  to  tape  filta  only 
'ICE  >>  TAPE).  It  spacifits  tha  nuir  of 
a  on  a  tapt. 

5  .>  [7  I  9] 

?ault  is  9. 


T1  UNCATE  attributt  spacifits  whathar  or  not 
rt  da  in  tha  file  art  truncatad  by  tliminatinq 
trailing  blanku.  Tht  TRUNCATE  attributt  applies 
only  to  files  opened  for  TEXT_,IO  in  IN^PILE  mode. 

TRUNCATE  »>  [YES  i 

If  TRUNCATE  >>  YES.  records  art  truncated. 

If  TRUNCATE  >>  NO.  records  art  not  truncated. 

Tht  default  is  NO. 
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VOL  HUM 


Dtscription:  Th«  VOL_(njM  attribut*  applias  to  tap*  Cllas  only 

(DEVICE  a>  TXPE).  It  ap*ci£i*s  th*  voluin*  s*qu*nc* 
numbor  of  a  tap*.  Volum*  s*qu*nc*  numbars  ar*  ustd 
whan  a  fll*  spans  savaral  tap*  volumas. 

Vaiuas;  VOL^NUM  «>  [1  ...  9999] 

Oafault:  Th*  dafault  is  1. 

ExampiM  of  FORM  Paramotar  Usage 

Th*  following  axamplas  illustrat*  th*  FORM  paranatar  as  it  appaars  in 
calls  to  th*  CREATE  or  OPEN  procadurast 

Ezanple  1 

CREATE(  FILE  =>  FD, 

MODE  =>  OUT_FILE. 

NAME  =)  ■•F0RT77.JM1#SRCE.TEST", 

FORM  a>  "DEVICE  :>  DISK.  ORGANIZATION  s>  PROGRAM, 

REC_SI2E  =>  1024,  REC_FORMAT  a>  F"  ); 

This  example  creates  a  program  file.  Not*  that  th*  DEVICE, 
REC^SIZE,  and  REC_FORMAT  attributes  could  b*  omitted,  since  the 
values  supplied  for  those  attributes  match  their  default  values. 

Example  2 

OPEN(  FILE  s>  FD, 

MODE  =>  IN_FILE. 

NAME  3>  "TAPE. JM1#SRCE. TEST”, 

FORM  =>  "DEVICE  »>  TAPE,  REC_SIZE  »>  80,  DENSITY  a>  6250, 
LABEL  =>  NONE"  ); 

This  example  opens  a  6250-bpi,  nonlabeled,  nine-track  tape  file  in 
read-only  mode.  Th*  tape  contains  80-byt*,  fixed-length, 
consecutive  records. 

Example  3 

CREATE (  FILE  «>  FD, 

MODE  «>  OUT^FILE, 

NAME  »>  ”F0RT77.#JM1PRT.PRTFILE", 

FORM  a>  "ORGANIZATION  »>  PRINT,  REC_SIZE  a>  134, 

COMPRESS  =>  YES,  BUF^SIZE  !>  18432"  ) ; 

This  example  creates  a  print  file  containing  134-byte  print 
records.  Th*  BUF_SIZE  attribute  specifies  an  ISR  DMS  buffer  to 
maximize  performance. 
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F.9  CHARACTERISTICS  OF  NUMERIC  TYPES 
F.9.1  Integer  Types 

Th«  rang»s  ot  values  for  integer  types  declared  in  package  STAMDAPO 
are  as  follows: 

SHORT  SHORT  INTEGER  -128  ..  127  —  -2**7  ..  2**7  -  1 


SHORT_INTEGER 

-32768  ..  32767  - 2**15 

. .  2**15  - 

1 

INTEGER 

-2147483648  ..  2147483647 

- 2**31 

.  .  2**31 

The  ranges  of  values  for  types  COUNT  and  POSITZVE_C0UNT  declared  in 
packages  0IR£CT_I0  and  TEXT_IO  are  as  follows: 

COUNT 

0  ..  2147483647 

—  0  .. 

2**31  -1 

POSITIVE_COUNT 

1  ..  2147483647 

—  1  .  . 

2**31  -1 

The  range  of  values 
as  follows: 

for  the  type  FIELD  declared 

in  package 

TEXT_I0 

FIELD 

0  ..  255 

—  0  .  . 

2**8  -1 

F.9.2  Floating  Point  Type  Attributes 

SHORT  FLOAT 


DIGITS 

MANTISSA 

EMAX 

EPSILON 

SMALL 

LARGE 

SAFE_EMAX 

SAFE^SMALL 

safe'large 

FIRST 

LAST 

MACHINE_RAOZX 

MACHINE~MANT1SSA 

MACHINE~EMAX 

machine'emin 

MACHINE^ROUNDS 

MACHINE”oVE8FLOWS 

SIZE 


6 

21 
84 
2.0 
2.0 
2.0  ** 
252 
2.0 
2.0 


** 


** 

** 


-20 
-85 
84  * 

-253 
252  * 


(1.0  -2.0  **  -21) 


(1.0  -  2.0  **  -21) 


-2.0  **  252  *  (1.0 


2.0 
16 
6 

63 

-64 

FALSE 

TRUE 

32 


** 


252  *  (1.0 


-  2.0  **  -24) 
■  2.0  *•  -24) 


Approximate 

Value 


9.54E-07 

2.5BE-26 

1.93E-f25 

6.91E-77 

7.24E+75 

-7.24E-I-75 

7.24E4.75 
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FLOAT 

Approxiiiiat* 

Value 


OZQXTS- 

IS 

MAMTZS8A 

31 

CHAX 

204 

EPSILON 

2.0  **  “50 

8.88E-16 

SHALL 

2.0  “205 

1.94B-62 

LAROB 

2.0  **  204  *  (1.0  -  2.0  **  “51) 

2.57E-»-61 

SAFB_EMAX 

252 

SAFE.SMALL 

2.0  **  -253 

6.91B-77 

SAFB.LARQB 

2.0  **  252  *  (1.0  -  2.0  **  -51) 

7.24B+75 

FIRST 

-2.0  **  252  *  (1.0  -  2.0  **  -56) 

-7.24B+75 

LAST 

2.0  **  252  *  (1.0  -  2.0  **  -56) 

7.24E-I-75 

MACHZNB.RAOZX 

16 

MACHZNB_MANTZSSA 

14 

MACHZNB.BMAX 

63 

MACHZNB.BMIN 

-64 

MACHINI.ROUNDS 

FALSE 

MACHINE.OVERFLONS 

TRUE 

SIZE 

€4 

Jkfe^rlbufcma  of 

Typ«  OniULTION 

OURATZCN' DELTA 

1 

0 

DURATION' SMALL 

2.0  -6 

DURATION' LARGE 

131072.0 

DURATION' FIRST 

-131072.0 

DURATION' LAST 

131071.0 
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r.10.1  Ouuraetarlstics  of  thm  Bmmp 

All  objects  created  by  allocators  70  Into  the  pcogram  heap.  In 
addition,  portions  of  the  Ada  runtime  system' s  representation  of  task 
objects,  including  the  task  stacks,  are  allocated  in  the  program  heap. 

All  objects  in  the  heap  belonging  to  a  given  collection  have  their 
storage  reclaimed  upon  exit  from  the  innermost  block  statement, 
subprogram  body,  or  task  body  that  encloses  the  access  type 
declaration  associated  with  the  collection.  For  access  types  declared 
at  the  library  level,  this  deallocation  occurs  only  upon  completion  of 
the  main  program. 
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No  Curthor  nutomatlc  atorag*  raclamatioa  ia  parformad;  i.a.  in  aCfact, 
all  aceass  typas  ara  daamad  to  bo  controllad  [4.8].  You  can  achlava 
asplicit  daal location  ot  tha  cbjact  dasignatad  by  an  accaas  valua  by 
calling  an  appropriata  instantiation  of  tha  ganaric  procaduro 
UNCHECXED_OEM.LOCAX  Z  OH . 

Spaca  for  the  heap  is  initially  claimed  from  tha  system  at  program 
start-up,  and  additional  spaca  may  be  claimed  as  rsguirad  whan  tha 
initial  allocation  is  axhaustad.  You  can  use  tha  binder  options  HEAP 
and  MOREKEAP  to  control  both  tha  size  of  tha  initial  allocation  and 
tha  size  of  tha  individual  increments.  You  can  also  use  ADAPATCK  to 
sat  these  values. 


F.10.2  Charact»risties  of  Tasks 

The  default  initial  task  stack  size  is  16  Kbytes.  Using  either  tha 
binder  option  TASK  or  the  ADAPATCH  program,  you  can  set  all  task 
stacks  in  a  program  to  any  size  from  4  Kbytes  to  16  Mbytes. 

Tha  maximum  number  of  active  tasks  is  limited  only  by  memory  usage. 
Tasks  release  their  storage  allocation  as  soon  as  they  have  terminated. 

Tha  acceptor  of  a  rendezvous  executes  the  accept  body  code  in  its  otni 
stack.  A  rendezvous  with  an  empty  accept  body  (e.g.  for 
synchronization)  need  not  cause  a  context  switch. 

The  main  program  waits  for  completion  of  all  tasks  dependent  on 
library  packages  before  terminating.  Such  tasks  may  select  a 
terminate  alternative  only  after  completion  of  the  main  program. 

Abnormal  completion  of  an  aborted  task  takes  place  immediately  unless 
the  abnormal  task  is  the  caller  of  an  entry  that  is  engaged  in  a 
rendezvous.  In  this  case,  abnormal  completion  of  the  task  takes  place 
as  soon  as  the  rendezvous  is  completed. 

A  global  deadlock  situation  arises  when  every  task,  including  the  main 
program,  is  waiting  for  another  task.  When  this  happens,  tha  program 
is  aborted  and  the  state  of  all  tasks  is  displayed. 


F.10.3  D«finition  of  f  Main  Program 

A  main  program  must  be  a  nongeneric  library  procedure  with  no 
parameters . 


F.10.4  Orctoring  of  Compilation  Units 

The  VS  Ada  compiler  imposes  no  ordering  constraints  on  compilations 
beyond  those  required  by  the  language. 
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F.10.5  lmpl«m«ntation-0»fined  Packages 

Th«  Collowinq  paclcagss  ar»  daflned  by  th*  VS  Ada  implamantation. 

Package  SYSTEM,ENViRONMENT 

Th«  VS-deCin«d  package  SYSTEM^ENVIRONMENT  enables  an  Ada  program  to 
communicate  with  the  environment  in  which  it  is  executed. 

The  specification  of  package  SYSTEM^ENVIROtTMENT  is  as  follows: 

package  SYSTEM_EKVIRONKEMT  is 

subtype  EXIT_STATUS  is  INTEGER : 

procedure  SET_EX1T_STATUS  (STATUS  :  in  EXIT_STATUS ) ; 
procedure  ABORT_PROGRAM  (STATUS  :  in  EXrT_STATUS ) ; 
procedure  CLEAR_SCREEN; 
end  SYSTEM_ENVIRONMENT; 

SET_EXIT_STATUS 

You  can  set  the  exit  status  of  the  program  (returned  in  register  0  on 
exit)  by  calling  SET^EXIT^STATUS.  Subsequent  calls  of  SET_EXIT_STATUS 
modify  the  exit  status;  the  status  finally  returned  is  the  status 
specified  by  the  last  executed  call  to  SET_EXIT_STATUS .  If 
SET__EXIT_STATUS  is  not  called,  the  value  0  is  returned. 

AaORT_PROGRAM 

You  can  cause  the  program  to  be  aborted,  returning  the  specified  exit 
code,  by  calling  the  ABORT_PROGRAM  procedure. 

CLEAR_SCREEN 

You  can  erase  the  entire  contents  of  the  ksr ation  screen  by  calling 

the  CI.EAR_SCREEN  procedure. 
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PiC!kag«  STRINGS 


Th*  VS  pACkAqn  STRINGS  it  «  uciliry  packaq«  chat  provid«a 

iKAity  con««OAly  r»quii«tl  atrinq  m«nipuI«tion  lAciliLiag. 

Th^  .tV'ac i f ICAt ion  ol  pA'.kAq*  STRINGS  ia  Aa  lollowai 

wicn  NHCHKCKKD^DEAUl  >  'TION; 
pacKAtjtt  STRINGh 


*  TYPES  * 


typ*  AGCCSS^STRING  is  Accaaa  STRING; 

pro-'AduiA  OEM.r.aOATE_STRIHG  la  ii*w  UNCHECKED_ntAM.QCAtION  (STRING, 

ACCESS  STRING); 


F-M  ’  «>■  i  Ration-  ki«f»\*nd»n  t  i 


,»r  vf  1  .rs 


*  UTILITIES  * 


function  UPPER  (C  :  in  CHARACTER)  rtturn  CHARACTER; 
function  UPPER  <S  :  in  STRING)  rtturu  STRING; 
procedure)  UPPER  (S  i  in  out  STRING); 

function  LOWER  (  in  CHARACTER)  return  CHARACTER; 
function  LOWER  (u  STRING)  return  STRING; 

procedure  LOWER  (St  o tt  STRING); 

function  CAPITAL  tS  i  TNG)  return  STRING; 
procedure  CAPITAL  (S  t  i.  STRING); 

function  REMOVE_LEAJDING_BLANKS  (S  i  in  STRING)  return  STRING; 
function  REMOVC_TRAILING_BLANKS  (S  :  in  STRING)  return  STRING) 
function  TRIM  (S  t  in  STRING)  return  STRING; 

function  INDEX  (C  i  in  CHARACTER) 

INTO  t  In  STRING; 

START  t  in  POSITIVE  i>  1)  return  NATURAL; 
function  INDEX  (S  i  in  STRING; 

INTO  t  in  STRING; 

START  t  in  POSITIVE  t«  1)  retu -n  NATURAL; 

function  NOT_INDEX  (C  i  in  CHARACTER; 

INTO  :  in  STRING; 

START  t  in  POSITIVE  I)  return  NATURAL; 
function  NOT_INDEX  (S  :  in  STRING; 

INTO  i  in  STRING; 

START  :  in  POSITIVE  i>  I)  return  NATURAL; 

function  1S_AN_ABBREV  (ABBREV  t  in  STRING; 

HILL  WORD  :  in  STRING; 

IGNORE_CASE  i  in  BOOLEAN  la  TRUE)  return  BOOLEAN 

function  MATCH_PATTERN  (S  i  in  STRING; 

PATTERN  I  in  STRING; 

IGNORC^CASEt  in  BOOLEAN  tu  TRUE)  return  BOOLEAN 

function  (LEFT  i  in  STRING;  RIGHT  i  in  STRING)  return  STRING; 

function  (LEFT  i  in  STRING;  RIGHT  i  in  CHARACTER)  return  STRING; 

function  (LEFT  i  in  CHARACTER;  RIGHT  >  in  STRING)  return  STRING; 

function  A’  (LEFT  :  in  CHARACTER;  RIGHT  t  in  CHARACTER)  return  STRING; 

end  STRINGS; 
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ACCESS^STRING 

Th«  ACCESS_STRING  typ*  la  a  convanitnc  declaration  o£  tna  commonly 
used  accasa  to  atrlnq  typa. 

DEAi.LOCATE_STRIMG 

Tha  DEALLOCXTE_STRING  procadura  la  an  instantiation  o£ 
UNCHECKED^DEALLOCATION  £or  tha  typa  ACCESS_STR1NG .  Mota  that  since 
tha  typa  ACCESS_SXRING  ia  declared  at  tha  library  level,  tha  scope  of 
the  corresponding  collection  ia  exited  only  at  program  completion. 

For  this  reason.  STRING  objects  belonging  to  this  collection  are  never 
automatically  deallocated.  It  ia  therefore  your  reaponsibi lity  to 
manage  the  deallocation  of  objects  within  this  collection. 

UPPER 

The  UPPER  subprograms  convert  any  lower  case-letters  in  their 
parameters  to  the  corresponding  upper-case  letters.  Characters  that 
are  not  lower-case  letters  are  not  affected.  The  procedure  is  more 
Qfficieut  than  the  corresponding  function,  as  it  does  not  use  the 
program  heap. 

LOWER 

The  LOWER  subprograms  convert  any  upper-case  letters  in  their 
parameters  to  the  corresponding  lower-case  letters.  Characters  that 
are  not  upper-case  letters  are  not  affected.  The  procedure  i.<i  more 
efficient  than  the  corresponding  function,  as  it  does  not  u.<it  the 
program  heap. 

CAPITAL 

The  CAPITAL  subprograms  "capitalise"  their  parameters.  That  is,  they 
convert  the  first  character  of  the  string  to  upper  case  and  all 
subsequent  cheracters  to  lower  case.  The  procedure  is  more  efficient 
than  the  corresponding  function,  as  it  does  not  use  the  program  heap. 

REMOVE__LEADIMG^BLANKS 

The  REMOVE_LCAi)ING_BLANKS  function  returns  its  parameter  string  with 
all  leading  spaces  removed. 

RtMOVE_TRArLIHG_BLANKS 

The  REMOVE_TRAiLING_BLANKS  function  returns  its  paremetar  string  with 
all  trailing  spaces  removed. 

TRIM 

The  TRIM  function  returns  its  peiamater  string  with  ail  leading  and 
trailing  spaces  removed. 
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INDEX 


th*  INDEX  subprograms  racurn  th*  Indax  into  r.h*  spacifiad  string 
(INTO)  of  tha  first  charactar  of  tha  first  occurranca  of  a  given 
substring  (S)  or  charactar  (C).  Tha  saarch  for  tha  substring  or 
charactar  commancas  at  tha  indax  spacifiad  by  START.  If  tha  substring 
or  charactar  is  not  found,  tha  functions  return  tha  value  0.  Casa  is 
significant . 

M0T_ INDEX 

Tha  NOT^INDEX  subprograms  raturn  tha  indax  into  tha  spacifiad  string 
(INTO)  of  tha  first  charactar  that  doas  not  occur  in  tha  given  string 
(S)  or  doas  not  match  tha  givan  charactar  (C).  Tha  saarch  for  tha 
noomatching  charactar  commancas  at  tha  indax  spacifiad  by  START.  If 
all  tha  characters  of  tha  string  match,  tha  functions  raturn  tha 
value  0.  Casa  is  significant. 

IS_AN_AflBREV 

Tha  IS_AN_A66REV  function  datarminas  whether  tha  string  ABBREV  is  an 
abbreviation  for  tha  string  rULL_WORD,  Leading  and  trailing  spaces  in 
ABBREV  are  first  removed,  and  tha  trimmed  string  is  than  considered  to 
be  an  abbreviation  for  rULL_WORD  if  it  is  a  proper  prefix  of  njLL^WOFD, 

Tha  parameter  IGNORE_CASE  controls  whether  or  not  case  is  significant. 

MAICH^PATTERN 

Tha  MATCH__PATTERN  function  datarminas  whether  tha  string  S  matches  tha 
pattern  spacifiad  in  PATTERN.  A  pattern  is  simply  a  string  in  which 
tha  character  is  considered  a  wild-card  that  can  match  any  number 
of  any  characters. 

For  example,  tha  string  "ABCDEFG"  matches  tha  pattern  "A*G"  and  tha 
pattern  "ABCD'»ErG*" . 

Tha  paramatar  IGNORE^CASE  controls  whethar  or  not  case  is  significant. 

Tha  package  STRINGS  also  provides  overloaded  sxtbprograins  designated  by 
'ti'.  These  are  identical  to  tha  corresponding  subprograms  daclarsd  in 
package  STANDARD,  except  that  tha  concatauations  are  performed  out  of 
line.  Performing  concatenations  out  of  lint  minimisas  tha  sisa  of  tha 
inline  generated  coda,  at  tha  expanse  of  execution  spaed. 


ImpJaiaantstion-uapandant  Charsctai  istics  F-6T 


